better way?

better way?

[tmoran]

I'd like to do something like:
  package Outer is

    type Inner_A_Thing_Type;
    type Inner_B_Thing_Type;

    package Inner_A is
      type Thing_Type is ...
      procedre P(X : access Inner_B_Thing_Type);
    end Inner_A;
    subtype Inner_A_Thing_Type is Inner_A.Thing_Type;

    package Inner_B is
      type Thing_Type is ...
      procedre Q(X : access Inner_A_Thing_Type);
    end Inner_B;
    subtype Inner_B_Thing_Type is Inner_B.Thing_Type;
    ...
  end Outer;

but the "subtype" instead of "type" prevents it.  Suggestions?

Re: better way?

[Robert Dewar]

In article <16D06.22140$A06.845242@news1.frmt1.sfba.home.com>,
  tmoran@acm.org wrote:
> but the "subtype" instead of "type" prevents it.

Well yes, of course, you cannot complete an incomplete
type declaration with a subtype declaration (I assume this
rule is clear).

You can complete with a derived type declaration is you like


Sent via Deja.com
http://www.deja.com/

Re: better way?

[mark_lundquist]

Well, it's _almost_ the "withing problem", and if you're using GNAT you
can use the "with type" language extension if you can live with making
the two "inner" packages child packages of the "outer" instead of
nesting them in "outer".

In article <16D06.22140$A06.845242@news1.frmt1.sfba.home.com>,
  tmoran@acm.org wrote:
> I'd like to do something like:
>   package Outer is
>
>     type Inner_A_Thing_Type;
>     type Inner_B_Thing_Type;
>
>     package Inner_A is
>       type Thing_Type is ...
>       procedre P(X : access Inner_B_Thing_Type);
>     end Inner_A;
>     subtype Inner_A_Thing_Type is Inner_A.Thing_Type;
>
>     package Inner_B is
>       type Thing_Type is ...
>       procedre Q(X : access Inner_A_Thing_Type);
>     end Inner_B;
>     subtype Inner_B_Thing_Type is Inner_B.Thing_Type;
>     ...
>   end Outer;
>
> but the "subtype" instead of "type" prevents it.  Suggestions?
>


Sent via Deja.com
http://www.deja.com/

Re: better way?

[Nick Roberts]

I believe the orthodox answer to this would be that, since the two types
Inner_A_Thing_Type and Inner_B_Thing_Type are so closely related, the
definitions of these types and their primitive operations all belong
immediately within the one package. I illustrate below (with names changed
to hopefully increase clarity a tad).


package MacDonalds_Ultra is

   type Diner_Type is [tagged] [limited] private;
   type Meal_Type is [tagged] [limited] private;

   procedure Eat (Diner: in out Diner_Type; Meal: in Meal_Type['Class]);
   procedure Configure_Nutritional_Balance (Meal: in out Meal_Type; Diner:
in Diner_Type['Class]);

   ...

private
   ...

end MacDonalds_Ultra;


It doesn't seem immediately obvious to me why you wouldn't want to adopt
this approach, at least as a starting point. Sometimes it is useful to
define further packages which present essentially the same types and
operations in a different way. I think Ada.Text_IO shows a fairly good
example of the meaningful use of inner packages.

--
Nick Roberts
http://www.AdaOS.org


<tmoran@acm.org> wrote in message
news:16D06.22140$A06.845242@news1.frmt1.sfba.home.com...
> I'd like to do something like:
>   package Outer is
>
>     type Inner_A_Thing_Type;
>     type Inner_B_Thing_Type;
>
>     package Inner_A is
>       type Thing_Type is ...
>       procedre P(X : access Inner_B_Thing_Type);
>     end Inner_A;
>     subtype Inner_A_Thing_Type is Inner_A.Thing_Type;
>
>     package Inner_B is
>       type Thing_Type is ...
>       procedre Q(X : access Inner_A_Thing_Type);
>     end Inner_B;
>     subtype Inner_B_Thing_Type is Inner_B.Thing_Type;
>     ...
>   end Outer;
>
> but the "subtype" instead of "type" prevents it.  Suggestions?

Re: better way?

[tmoran]

>...Inner_A_Thing_Type and Inner_B_Thing_Type are so closely related, the
>definitions of these types and their primitive operations all belong
  The problem is that there are two (or more) (sub)packages, each of
which defines a Thing_Type, and each of which has zero or more procedures
that need to access the *other* package's Thing_Type.  I want compile
time checking that the right Things are being passed to the various
procedures.  Also, this code is coming out of a special purpose code
generator, so major changes in the package structure are highly undesirable.