parent package referring to child

parent package referring to child

[eliben]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="iso-8859-8-i", Size: 687 bytes --]

Hello,

I have a package FOO that encapsulates a large part of the system. Now
I need to add to it a public type (that should be visible by external
code) with a lot of enumerated names (hundreds). I don't want to fill
the spec of FOO with this huge type, so I thought it would be a good
idea to create a subpackage: FOO.Names, and place the type there.

However, declarations of subprograms in the spec of FOO must refer to
the names from FOO.Names, and Ada 95 won't let me do that because it's
parent referring to child.

Is there any way to overcome this problem ? Perhaps a different design
that suits the requirement and doesn't go against the Ada standard ?

Thanks in advance.

Re: parent package referring to child

[Georg Bauhaus]

On Tue, 2007-10-09 at 23:23 -0700, eliben wrote:
> Hello,
> 
> I have a package FOO that encapsulates a large part of the system. Now
> I need to add to it a public type (that should be visible by external
> code) with a lot of enumerated names (hundreds). I don't want to fill
> the spec of FOO with this huge type, so I thought it would be a good
> idea to create a subpackage: FOO.Names, and place the type there.

> However, declarations of subprograms in the spec of FOO must refer to
> the names from FOO.Names, and Ada 95 won't let me do that because it's
> parent referring to child.

You can replicate the type as a derived type in FOO and create
the Names package as a normal package:

  type Twin is new Names.Huge;

Another possibility is to rearrange the package hierarchy so
that FOO can become a sibling of Names.

(Sometimes I think a folding editor is a Good Thing, once
I get used to it. The same with source navigation. :)

Re: parent package referring to child

[eliben]

On Oct 10, 11:07 am, Georg Bauhaus <rm.tsoh
+bauh...@maps.futureapps.de> wrote:
> On Tue, 2007-10-09 at 23:23 -0700, eliben wrote:
> > Hello,
>
> > I have a package FOO that encapsulates a large part of the system. Now
> > I need to add to it a public type (that should be visible by external
> > code) with a lot of enumerated names (hundreds). I don't want to fill
> > the spec of FOO with this huge type, so I thought it would be a good
> > idea to create a subpackage: FOO.Names, and place the type there.
> > However, declarations of subprograms in the spec of FOO must refer to
> > the names from FOO.Names, and Ada 95 won't let me do that because it's
> > parent referring to child.
>
> You can replicate the type as a derived type in FOO and create
> the Names package as a normal package:
>
>   type Twin is new Names.Huge;
>

True, but this would make Names and FOO seem unrelated, which they're
not. It would be a shame.

> Another possibility is to rearrange the package hierarchy so
> that FOO can become a sibling of Names.
>

Why does it make sense that two siblings can see each other in their
specs when they "with" each other, but a parent can't see a child ?

Eli

Re: parent package referring to child

[Adam Beneschan]

On Oct 10, 2:24 am, eliben <eli...@gmail.com> wrote:


> Why does it make sense that two siblings can see each other in their
> specs when they "with" each other

You can't have two siblings "with" each other in their specs.  One can
"with" the other, but not both.  You cannot declare a package
Parent.Child1 that with's Parent.Child2, and at the same time
Parent.Child2 with'ing Parent.Child1.  One of the siblings has to come
first.  ("Limited with" can help get around some of the problems.)

> but a parent can't see a child ?

Think about it.  Something has to come first.  If B "with's" A, then A
has to exist before B can be compiled (i.e. A's specification).  Can a
child come into existence before its parent?

                         -- Adam

Re: parent package referring to child

[Matthew Heaney]

On Oct 10, 2:23 am, eliben <eli...@gmail.com> wrote:
>
> However, declarations of subprograms in the spec of FOO must refer to
> the names from FOO.Names, and Ada 95 won't let me do that because it's
> parent referring to child.

You can do this in Ada05:

limited with P.C;
package P is
   procedure Op (O : in out P.C.T);
end P;

package P.C is
   type T is tagged null record;
end P.C;

Re: parent package referring to child

[Jeffrey R. Carter]

eliben wrote:
> 
> I have a package FOO that encapsulates a large part of the system. Now
> I need to add to it a public type (that should be visible by external
> code) with a lot of enumerated names (hundreds). I don't want to fill
> the spec of FOO with this huge type, so I thought it would be a good
> idea to create a subpackage: FOO.Names, and place the type there.

FOO seems the logical place to declare the type. Its size seems immaterial.

-- 
Jeff Carter
"We use a large, vibrating egg."
Annie Hall
44

Re: parent package referring to child

[Vadim Godunko]

On Oct 10, 6:59 pm, Matthew Heaney <mhea...@on2.com> wrote:
> On Oct 10, 2:23 am, eliben <eli...@gmail.com> wrote:
>
>
>
> > However, declarations of subprograms in the spec of FOO must refer to
> > the names from FOO.Names, and Ada 95 won't let me do that because it's
> > parent referring to child.
>
> You can do this in Ada05:
>
> limited with P.C;
> package P is
>    procedure Op (O : in out P.C.T);
                   O : access P.C.T
You can't use "in out" mode, T have only limited view at this point.

Re: parent package referring to child

[anon]

Some time package can get too large to handle there are a few ways to 
handle this in all Ada's spec.

The non-standard Ada way is to use "pragma Import" "pragma Export" 
statements.


The standard Ada way is to use the "seperate" paradigm.

That is split the FOO package into smaller files and use the "seperate" 
statement to relink them. To test for errors and build the package use 
"gnat compile foo.adb" the compile will load and compile all seperate 
packages that are in FOO package.

  -- ------------- --
  -- File: Foo.ads --
  -- ------------- --
  package body Foo is 

    procedure Local_Foo ;

  end Foo ;

  -- ------------- --
  -- File: Foo.adb --
  -- ------------- --

  package body Foo is 

   --
   -- spec for seperate packages and routines
   --

    package Ch10 is
      -- spec
    end Ch10 ;


    package Ch11 is
      -- spec
    end Ch11 ;

    procedure Load ;



    use Ch10 ;
    use Ch11 ;

    --
    -- Define children bodies are in external files with name 
    -- PARENT-CHILD.adb
    --

    package body Ch10 is separate ;
    package body Ch11 is separate ;
    procedure Load is separate ;

    --
    -- local procedures and those that are visible to the 
    -- outsise
    --
    procedure Local_Foo is
      ...
      begin -- Local_Foo
        ...
      end Local_Foo ;

    ...

  end Foo ;


  -- ------------------ --
  -- File: foo-ch10.adb --
  -- ------------------ --
  separate (Foo)
  package body Ch10 is
   ... 
  end Ch10 ;


  -- ------------------ --
  -- File: foo-ch11.adb --
  -- ------------------ --
  separate (Foo)
  package body Ch11 is
    ...
  end Ch11 ;


  -- ------------------ --
  -- File: foo-load.adb --
  -- ------------------ --
  separate (Foo)
  procedure Load is
    ...
  begin -- Load
    ...
  end Load ;




In <1191997397.865251.322480@d55g2000hsg.googlegroups.com>,  eliben <eliben@gmail.com> writes:
>Hello,
>
>I have a package FOO that encapsulates a large part of the system. Now
>I need to add to it a public type (that should be visible by external
>code) with a lot of enumerated names (hundreds). I don't want to fill
>the spec of FOO with this huge type, so I thought it would be a good
>idea to create a subpackage: FOO.Names, and place the type there.
>
>However, declarations of subprograms in the spec of FOO must refer to
>the names from FOO.Names, and Ada 95 won't let me do that because it's
>parent referring to child.
>
>Is there any way to overcome this problem ? Perhaps a different design
>that suits the requirement and doesn't go against the Ada standard ?
>
>Thanks in advance.
>

Re: parent package referring to child

[Simon Wright]

Georg Bauhaus <rm.tsoh+bauhaus@maps.futureapps.de> writes:

> You can replicate the type as a derived type in FOO and create
> the Names package as a normal package:
>
>   type Twin is new Names.Huge;
>
> Another possibility is to rearrange the package hierarchy so
> that FOO can become a sibling of Names.

Foo and Foo_Names perhaps. We use a code generator, the things it
can't generate are by convention in Foo_Support.

One possible problem is that the literals aren't directly visible in
Foo without 'use Foo_Names'.

Re: parent package referring to child

[Matthew Heaney]

On Oct 10, 2:54 pm, Vadim Godunko <vgodu...@gmail.com> wrote:
>
> > You can do this in Ada05:
>
> > limited with P.C;
> > package P is
> >    procedure Op (O : in out P.C.T);
>
>                    O : access P.C.T
> You can't use "in out" mode, T have only limited view at this point.

No, that's wrong.  In this case you can use mode inout because type T
is tagged (meaning that it's passed by reference).  Try it!

Re: parent package referring to child

[Matthew Heaney]

On Oct 10, 10:59 am, Matthew Heaney <mhea...@on2.com> wrote:
>
> You can do this in Ada05:
>
> limited with P.C;
> package P is
>    procedure Op (O : in out P.C.T);
> end P;
>
> package P.C is
>    type T is tagged null record;
> end P.C;

If you want to really impress your family and friends, you can say:

limited private with P.C;
package P is
   -- public stuff here
private
   procedure Op (O : in out P.C.T);
end P;

Re: parent package referring to child

[Adam Beneschan]

On Oct 10, 12:32 pm, Matthew Heaney <mhea...@on2.com> wrote:
> On Oct 10, 2:54 pm, Vadim Godunko <vgodu...@gmail.com> wrote:
>
>
>
> > > You can do this in Ada05:
>
> > > limited with P.C;
> > > package P is
> > >    procedure Op (O : in out P.C.T);
>
> >                    O : access P.C.T
> > You can't use "in out" mode, T have only limited view at this point.
>
> No, that's wrong.  In this case you can use mode inout because type T
> is tagged (meaning that it's passed by reference).

I don't see what the parameter mode has to do with it.  I can't find a
rule that would make "procedure Op (O : in P.C.T);" illegal.  Also,
GNAT accepts it in a small test case I just tried, although that
doesn't necessarily mean much (see below).  Then again, on second
reading, maybe I read too much into what you said.

Also, the "by reference" comment isn't relevant either.  If the
package that you're LIMITED WITH'ing contains an untagged type, you
can't use it as a parameter of any mode except "access", regardless of
whether it's a by-reference type.  The relevant rules are 3.10.1(5-9),
which spell out what an "incomplete view" of a type can be used for
(including a type declared in a LIMITED WITH'ed package); the rules
are different for tagged and untagged types (or, technically, tagged
and untagged incomplete views of types).


> Try it!

That doesn't seem to be particularly good advice.  You can "try it"
only by running it through a compiler, but that still won't tell you
whether the code is illegal because many compilers accept a lot of
code that they shouldn't.  I know GNAT has accepted plenty of illegal
code in the past.  (Some of the bugs have been fixed in later
versions.)

                      -- Adam

Re: parent package referring to child

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message
news:1192047607.865747.220890@50g2000hsm.googlegroups.com...
> On Oct 10, 12:32 pm, Matthew Heaney <mhea...@on2.com> wrote:
...
> > No, that's wrong.  In this case you can use mode inout because type T
> > is tagged (meaning that it's passed by reference).
>
> I don't see what the parameter mode has to do with it.

The mode has nothing do to with it; but the rule is that a tagged incomplete
type (which is what you get in a limited view) can be used as a parameter.
See 3.101(8.2/2).

>  I can't find a rule that would make "procedure Op (O : in P.C.T);"
illegal.

It's the absence of a rule: see the only allowed uses for incomplete types:
see 3.10.1(5-9.4/2). Note that 3.10.1(9.4/2) says that no other uses are
allowed. Use as a parameter is not allowed for untagged types.

...
> Also, the "by reference" comment isn't relevant either.

It is relevant as it is the reason that tagged incomplete types can be used
as parameters (because the compiler doesn't need to know the real type in
order to know how it is passed as a parameter - this same property is needed
to be able to deal with classwide types which is why it is fundamental to
tagged types); you don't know that for untagged types so they aren't
allowed.

I think I was the originator of this idea; it allows you to make classwide
calls for objects of types that you don't actually know about. (I'm not sure
that it is as useful as I originally thought, but it certainly is a
less-restrictive rule.)

...
> > Try it!
>
> That doesn't seem to be particularly good advice.  You can "try it"
> only by running it through a compiler, but that still won't tell you
> whether the code is illegal because many compilers accept a lot of
> code that they shouldn't.  I know GNAT has accepted plenty of illegal
> code in the past.  (Some of the bugs have been fixed in later
> versions.)

I think Matt was trying more to convince the skeptical that this works. But
I agree that you can't rely only on a compiler to realize that this works;
it helps to know the rules and motivation.

                         Randy.

Re: parent package referring to child

[george]

eliben wrote:
> I have a package FOO that encapsulates a large part of the system. Now
[..]
> Is there any way to overcome this problem ? Perhaps a different design
> that suits the requirement and doesn't go against the Ada standard ?
I have been faced with just such a problem, when writing a library to
access abf files (a special data format used by the most common
software in electrophysiology). I needed to define a record type with
near a thousand fields (beat you here ;)) and did not want to put it
all into the single spec. My solutions was exactly redesign, or rather
I designed it from ground up to be appropriately split between the
parent and child modules.

On top there was ABF with the most common (elementary) types. Then
there were children. ABF.Header to keep the big struct and IO ops
specific to the header part. ABF.Data, ABF.Synth, etc (some with
further children) for dealing with the corresponding parts of data
file (it can have one of a few modes each of which imposed a somewhat
different layout of the data). All children would naturally see ABF
and most would with the ABF.Header, as necessary. In the further
development (this one not finished actually) I even split that big
struct off into a private child with the intention of creating a
somewhat "thicker" "binding" (to the data layout).

You may try playing with Ada-2005 features, as others suggested, but
that seems to require making the corresponding type tagged. Plus, in
the long run and for a non-trivial problem, it may be well worth
splitting or designing the split early in the process. Of course it is
up to you to know best, what is the appropriate way (for example, if
the overall structure of the project is expected to be plain and not
extensible it may be better to try to make limited with do what you
need instead).

George

Re: parent package referring to child

[Adam Beneschan]

On Oct 10, 9:12 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Adam Beneschan" <a...@irvine.com> wrote in message
>
> news:1192047607.865747.220890@50g2000hsm.googlegroups.com...
>
> > On Oct 10, 12:32 pm, Matthew Heaney <mhea...@on2.com> wrote:
> ...
> > > No, that's wrong.  In this case you can use mode inout because type T
> > > is tagged (meaning that it's passed by reference).
>
> > I don't see what the parameter mode has to do with it.
>
> The mode has nothing do to with it; but the rule is that a tagged incomplete
> type (which is what you get in a limited view) can be used as a parameter.
> See 3.101(8.2/2).
>
> >  I can't find a rule that would make "procedure Op (O : in P.C.T);"
>
> illegal.
>
> It's the absence of a rule: see the only allowed uses for incomplete types:
> see 3.10.1(5-9.4/2). Note that 3.10.1(9.4/2) says that no other uses are
> allowed. Use as a parameter is not allowed for untagged types.

Right... I was under the impression that we were assuming T was
tagged.


> > Also, the "by reference" comment isn't relevant either.
>
> It is relevant as it is the reason that tagged incomplete types can be used
> as parameters (because the compiler doesn't need to know the real type in
> order to know how it is passed as a parameter - this same property is needed
> to be able to deal with classwide types which is why it is fundamental to
> tagged types); you don't know that for untagged types so they aren't
> allowed.

Yep, that makes sense.  My point was that using a parameter is illegal
for untagged by-reference types, just as for untagged by-copy types.
But if you're looking at a limited view, you aren't allowed to know
enough about the type to know whether an untagged type is by-reference
or by-copy.  I missed that---thanks for the explanation.

                  -- Adam

Re: parent package referring to child

[Jeffrey R. Carter]

george@gentoo.org wrote:
> I have been faced with just such a problem, when writing a library to
> access abf files (a special data format used by the most common
> software in electrophysiology). I needed to define a record type with
> near a thousand fields (beat you here ;)) and did not want to put it
> all into the single spec. My solutions was exactly redesign, or rather
> I designed it from ground up to be appropriately split between the
> parent and child modules.

This perhaps makes sense for this specific situation (files with a 
number of different layouts, based on the data at the beginning of the 
file), but I don't understand this attitude in general. Given the basic 
package structure

package P is
    type T is ...

    procedure P1 (V : [mode] T ...);
    procedure P2 (V : [mode] T ...);
    ... -- Additional operations as needed.
end P;

why do some seem to think it's OK to have T declared here if the 
declaration is short, but not if it is (perceived to be) long? It's the 
same concept in both cases and should, I think, be implemented in a 
uniform way.

-- 
Jeff Carter
"You tiny-brained wipers of other people's bottoms!"
Monty Python & the Holy Grail
18

Re: parent package referring to child

[Georg Bauhaus]

Jeffrey R. Carter wrote:

> 
> package P is
>    type T is ...
> 
>    procedure P1 (V : [mode] T ...);
>    procedure P2 (V : [mode] T ...);
>    ... -- Additional operations as needed.
> end P;
> 
> why do some seem to think it's OK to have T declared here if the 
> declaration is short, but not if it is (perceived to be) long? It's the 
> same concept in both cases and should, I think, be implemented in a 
> uniform way.

A number of coding styles seem to emphasise quick pattern
recognition by humans. (Not to mention the all important
typographical issues, viz. dresscode).
Short packages can be perceived to have advantages for the
quick, pragmatical programmer when viewed in dumb terminals.

In program structure, form and function may have relations that
are more intricate than technical views might suggest. The
influential factors are outside the programming language, though.

I guess the partial classes of C# will help with this goal, too.

Re: parent package referring to child

[Vadim Godunko]

On Oct 11, 8:12 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
> I think I was the originator of this idea; it allows you to make classwide
> calls for objects of types that you don't actually know about. (I'm not sure
> that it is as useful as I originally thought, but it certainly is a
> less-restrictive rule.)
>
Thanks Matthew and Randy for hint and explanation ;-)

This is really useful (at least for me)! In QtAda binding I have two
types Q_Char and Q_String. Its operations have several cross
references. For use its operations in prefixed view I need to make it
tagged. This is not raise any problem. But with out mentioned rules I
must use anonymous access types for parameters (this is bad, objects
always distinguishable through it values, no reference semantic is
needed) or define both types in same package (this is not so good,
both classes has large API).