Need advice re package organization.

Need advice re package organization.

[Bobby D. Bryant]

Most of my work with Ada has involved either smallish programs or simple
self-contained library units where a good package organization was
obvious, but now I'm doing something with several layers of interrelated
parts and I'd like to get some experienced advice on how to organize my
components into packages.

For the (n+1)th revision of my research code I'm going to break up my
neural network implementation into a hierarchy of objects, not a
derivational hierarchy but a hierarchy of objects composed from more
elementary objects.  In particular I'll start with some atomic types for
weights, activation accumulators, etc., implement neurons as compositions
of those atomic types, layers as compositions of neurons, and networks as
compositions of layers.  Each component will have various utility
procedures and functions in addition to the type definitions, and most of
the types will be tagged types to facilitate the creation of derived types
for instrumenting the behavior of individual objects and some other odd
things I do in my research.

The intent of that component design is to allow programs or auxiliary
packages to manipulate networks as high-level abstractions, but to be able
to reach down and manipulate a layer or a neuron directly when necessary.
My question is how would be the best way to translate that structural
hierarchy into Ada packages.  Three obvious solutions come to mind:

1) Roll everything into a single package.

2) Create an independent package for each level of the hierarchy,
"with"ing the other packages as needed.

3) Create a lean parent package and implement each object in a separate
child package, "with"ing the others as needed.

The third does not seem a very obvious solution to me, but I'm considering
it because that's generally how GtkAda is organized.  However, the
hierarchy flattened by the GtkAda package structure is more a derivational
hierarchy than a compositional hierarchy, so I don't know whether the same
design considerations would apply.

Any suggestions, either for my specific example or for more general
considerations?

Thanks,

-- 
Bobby Bryant
Austin, Texas

Re: Need advice re package organization.

[Robert I. Eachus]

Bobby D. Bryant wrote:

 > Any suggestions, either for my specific example or for more general
 > considerations?

The "right" answer to this question tends to be heuristic.  One package
is probably too few, one (child) package per final type may be too many.

If your (final) object types are going to be composed of component 
types, you almost certainly want one set of packages of components, and 
another of objects.  I would start with that organization, and 
specialize using child packages if there are types that are difficult to 
implement, not generally used, or where collisions between operation 
names are going to cause problems when you have a use clause for the 
main package.

Figuring out the best organization is tough, and often you will discover 
a problem with the hierarchy you have chosen once you start implementing 
it.  Don't worry, go ahead and change it.  That is what text editors are 
for.  You don't need to find the perfect decomposition, just avoid bad 
ones.  And a bad decomposition shows up when it starts making work for 
you, rather than eliminating it.

Of course, whatever organization you choose, you should sketch it out 
first, write the package specs, the main program, and then the package 
bodies.

-- 
                                               Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac,
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: Need advice re package organization.

[Warren W. Gay VE3WWG]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:3F228F3B.9020203@attbi.com...
> Bobby D. Bryant wrote:
>
>  > Any suggestions, either for my specific example or for more general
>  > considerations?
>
> The "right" answer to this question tends to be heuristic.  One package
> is probably too few, one (child) package per final type may be too many.
>
> If your (final) object types are going to be composed of component
> types, you almost certainly want one set of packages of components, and
> another of objects.  I would start with that organization, and
> specialize using child packages if there are types that are difficult to
> implement, not generally used, or where collisions between operation
> names are going to cause problems when you have a use clause for the
> main package.
>
> Figuring out the best organization is tough, and often you will discover
> a problem with the hierarchy you have chosen once you start implementing
> it.  Don't worry, go ahead and change it.  That is what text editors are
> for.  You don't need to find the perfect decomposition, just avoid bad
> ones.  And a bad decomposition shows up when it starts making work for
> you, rather than eliminating it.
>
> Of course, whatever organization you choose, you should sketch it out
> first, write the package specs, the main program, and then the package
> bodies.

All of this is good advice. When structuring your packages, keep in the
back of your mind the visibility and access rules that Ada insists upon.
For example, you'll have to avoid any circular package references (a
poor hierarchy will have a package trying to with a package that has
already been with-ed by it, creating a circular dependency). Another
catch may be a "support" package, that cannot gain access to the
necessary types of a set of parent/child packages (due to circular
references).

Parent/child package relationships themselves can get tricky. From a
software design perspective, you want to limit visibility for safety,
and yet the child packages enjoy full visibility of the private parts
of the parent. Yet, when the same package is moved outside of
the parent/child hierarchy, you enjoy the limited visibility you want,
but then you may not have the visibility to types and API's that you
might need.

[As a side note, I sometimes wonder if an enhancement to the Ada0Y
language might be to be able to specify a limited visibility of a
parent package's object's internals (a la not "protected" type in
C++). A protected class in C++ allows derived code to mess with the
internals, whereas normally the parent object's elements are a
black box. Use of limited visibility helps to reduce code coupling.]

I have found the object relationships are easier to define, and these
should perhaps be done first (perhaps initially as one package). After
this has been "purified/tested", then see how this can be broken down
into separate and perhaps "optional" packages and child packages.

Package visibility rules make the packaging more difficult, in my own
experience. Obviously if the project is huge, you'll want to define
the objects and package hierarchy up front (for sanity and quicker
development). It might also be stated that this is good practice
anyway, and should always be done this way.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Need advice re package organization.

[Robert I. Eachus]

Warren W. Gay VE3WWG wrote:

> [As a side note, I sometimes wonder if an enhancement to the Ada0Y
> language might be to be able to specify a limited visibility of a
> parent package's object's internals (a la not "protected" type in
> C++). A protected class in C++ allows derived code to mess with the
> internals, whereas normally the parent object's elements are a
> black box. Use of limited visibility helps to reduce code coupling.]

Actually, that is what a private child package is for.  It allows you to 
move all of the "useful" internals out of a package body to a place 
where the body and all the child packages can access them.

-- 
                                              Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: Need advice re package organization.

[chris]

Robert I. Eachus wrote:
> 
> Actually, that is what a private child package is for.  It allows you to 
> move all of the "useful" internals out of a package body to a place 
> where the body and all the child packages can access them.

What is a private child package?

Re: Need advice re package organization.

[Robert I. Eachus]

chris wrote:
> What is a private child package?

private package Parent.Private_Child is... end Parent.Private_Child;

See RM 10.1.1(12), and 10.1.2(8). Probably one of the best kept secrets 
in Ada 95.  A private child package can have a with clause for another 
private child of the same parent (or ancestor package), but the real use 
is that the body of the parent package or any sibling can with the 
private package.

So if you have common utility routines that you don't want to make part 
of the parent's package spec, put them in a private child.  For example, 
the parent package might export a private type, and the private child 
could include the inquiry functions and other operations that needed to 
see into the private part of the parent.

-- 
"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: Need advice re package organization.

[Richard Riehle]

"Robert I. Eachus" wrote:

> chris wrote:
> > What is a private child package?
>
> private package Parent.Private_Child is... end Parent.Private_Child;
>
> See RM 10.1.1(12), and 10.1.2(8). Probably one of the best kept secrets
> in Ada 95.  A private child package can have a with clause for another
> private child of the same parent (or ancestor package), but the real use
> is that the body of the parent package or any sibling can with the
> private package.

One of the most ideas related to private children is the potential for
aspect-oriented programming (AOP).   The idea of cross-cutting
common facilities across a larger design while preserving encapsulation
is nicely accomplished with private chilren.

> So if you have common utility routines that you don't want to make part
> of the parent's package spec, put them in a private child.  For example,
> the parent package might export a private type, and the private child
> could include the inquiry functions and other operations that needed to
> see into the private part of the parent.

This allows us to promote any feature of a package body to a private
package specification.  What this means is that the package body
should only contain implementations in the specification.  Any other
functions or procedures should be declared in a private package
specification.  Once this is done,  those specifications are themselves
extensible.   Also, every set of subprograms is declared at the
specification level.  Voila, we have a model for AOP.

Of course, I do oversimplify in this description, but anyone who
explores this in depth will soon discover the validity of this
notion.

Richard Riehle

Re: Need advice re package organization.

[Warren W. Gay VE3WWG]

Robert I. Eachus" <rieachus@attbi.com> wrote in message news:3F22F9E9.3040307@attbi.com...
> Warren W. Gay VE3WWG wrote:
>
> > [As a side note, I sometimes wonder if an enhancement to the Ada0Y
> > language might be to be able to specify a limited visibility of a
> > parent package's object's internals (a la not "protected" type in
> > C++). A protected class in C++ allows derived code to mess with the
> > internals, whereas normally the parent object's elements are a
> > black box. Use of limited visibility helps to reduce code coupling.]
>
> Actually, that is what a private child package is for.  It allows you to
> move all of the "useful" internals out of a package body to a place
> where the body and all the child packages can access them.

Actually, what I had in mind was the object visibility here (not
package visibility). When deriving from existing tagged records, there
is no way to limit the visibility of the parent object's members (a
la "protected" in C++/Java). A derived object can freely mess with any
tagged record's members, as it sees fit. Information hiding
and reduced coupling practices suggests that this is not the safest
route (best to use the existing parent object methods to mess with
the "parent members").

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Need advice re package organization.

[Dmitry A. Kazakov]

On Sun, 27 Jul 2003 18:02:08 -0400, "Warren W. Gay VE3WWG"
<ve3wwg@cogeco.ca> wrote:

>Robert I. Eachus" <rieachus@attbi.com> wrote in message news:3F22F9E9.3040307@attbi.com...
>> Warren W. Gay VE3WWG wrote:
>>
>> > [As a side note, I sometimes wonder if an enhancement to the Ada0Y
>> > language might be to be able to specify a limited visibility of a
>> > parent package's object's internals (a la not "protected" type in
>> > C++). A protected class in C++ allows derived code to mess with the
>> > internals, whereas normally the parent object's elements are a
>> > black box. Use of limited visibility helps to reduce code coupling.]
>>
>> Actually, that is what a private child package is for.  It allows you to
>> move all of the "useful" internals out of a package body to a place
>> where the body and all the child packages can access them.
>
>Actually, what I had in mind was the object visibility here (not
>package visibility). When deriving from existing tagged records, there
>is no way to limit the visibility of the parent object's members (a
>la "protected" in C++/Java). A derived object can freely mess with any
>tagged record's members, as it sees fit. Information hiding
>and reduced coupling practices suggests that this is not the safest
>route (best to use the existing parent object methods to mess with
>the "parent members").

I do not know whether there is a statistics regarding use protected
vs. private, but I think that most C++ programmers just stick to
public vs. not. Burden of decision is too heavy for many.

What I would like to have

1. multiple parents;

2. an ability to choose which members are public and which are not
(presently one needs a two-stage deriving);

3. an ability to have public read-only members with full access in the
private part;

4. a finer control over overridings (a vast theme).

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Need advice re package organization.

[Warren W. Gay VE3WWG]

Dmitry A. Kazakov wrote:
> On Sun, 27 Jul 2003 18:02:08 -0400, "Warren W. Gay VE3WWG"
> <ve3wwg@cogeco.ca> wrote:
>>Robert I. Eachus" <rieachus@attbi.com> wrote in message news:3F22F9E9.3040307@attbi.com...
>>>Warren W. Gay VE3WWG wrote:
>>>>[As a side note, I sometimes wonder if an enhancement to the Ada0Y
>>>>language might be to be able to specify a limited visibility of a
>>>>parent package's object's internals (a la not "protected" type in
>>>>C++). A protected class in C++ allows derived code to mess with the
>>>>internals, whereas normally the parent object's elements are a
>>>>black box. Use of limited visibility helps to reduce code coupling.]
>>>
>>>Actually, that is what a private child package is for.  It allows you to
>>>move all of the "useful" internals out of a package body to a place
>>>where the body and all the child packages can access them.
>>
>>Actually, what I had in mind was the object visibility here (not
>>package visibility). When deriving from existing tagged records, there
>>is no way to limit the visibility of the parent object's members (a
>>la "protected" in C++/Java). A derived object can freely mess with any
>>tagged record's members, as it sees fit. Information hiding
>>and reduced coupling practices suggests that this is not the safest
>>route (best to use the existing parent object methods to mess with
>>the "parent members").
> 
> I do not know whether there is a statistics regarding use protected
> vs. private, but I think that most C++ programmers just stick to
> public vs. not. Burden of decision is too heavy for many.

Many of these issues are tough to decide up front, particularly
if these are libraries for users to use. However, when I used
C++, I tended to leave protected out (disallowing access to
internal members), until I had a good reason to do otherwise.

While it has been a while since I looked at M$ code, I believe they
use it (or not, depending upon its intended use) displaying some
decision making there.

> What I would like to have
> 
> 1. multiple parents;

This could be useful, no doubt. But it also introduces new
issues but I suppose I would reluctantly endorse MI if pressed
to make a choice.

> 2. an ability to choose which members are public and which are not
> (presently one needs a two-stage deriving);

Yes.

> 3. an ability to have public read-only members with full access in the
> private part;

Yes. Even C++ lacks this. However, one could argue that you should
always provide an "interface" to these, but from a practical level,
I find this a big pain.

> 4. a finer control over overridings (a vast theme).

Certainly an area of discussion. The practical question is whether
things need to be done about the present scheme of things, or not.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Need advice re package organization.

[Dmitry A. Kazakov]

On Tue, 29 Jul 2003 13:18:29 -0400, "Warren W. Gay VE3WWG"
<ve3wwg@cogeco.ca> wrote:

>Dmitry A. Kazakov wrote:
>> On Sun, 27 Jul 2003 18:02:08 -0400, "Warren W. Gay VE3WWG"
>> <ve3wwg@cogeco.ca> wrote:
>>>Robert I. Eachus" <rieachus@attbi.com> wrote in message news:3F22F9E9.3040307@attbi.com...
>>>>Warren W. Gay VE3WWG wrote:
>>>>>[As a side note, I sometimes wonder if an enhancement to the Ada0Y
>>>>>language might be to be able to specify a limited visibility of a
>>>>>parent package's object's internals (a la not "protected" type in
>>>>>C++). A protected class in C++ allows derived code to mess with the
>>>>>internals, whereas normally the parent object's elements are a
>>>>>black box. Use of limited visibility helps to reduce code coupling.]
>>>>
>>>>Actually, that is what a private child package is for.  It allows you to
>>>>move all of the "useful" internals out of a package body to a place
>>>>where the body and all the child packages can access them.
>>>
>>>Actually, what I had in mind was the object visibility here (not
>>>package visibility). When deriving from existing tagged records, there
>>>is no way to limit the visibility of the parent object's members (a
>>>la "protected" in C++/Java). A derived object can freely mess with any
>>>tagged record's members, as it sees fit. Information hiding
>>>and reduced coupling practices suggests that this is not the safest
>>>route (best to use the existing parent object methods to mess with
>>>the "parent members").
>> 
>> I do not know whether there is a statistics regarding use protected
>> vs. private, but I think that most C++ programmers just stick to
>> public vs. not. Burden of decision is too heavy for many.
>
>Many of these issues are tough to decide up front, particularly
>if these are libraries for users to use. However, when I used
>C++, I tended to leave protected out (disallowing access to
>internal members), until I had a good reason to do otherwise.
>
>While it has been a while since I looked at M$ code, I believe they
>use it (or not, depending upon its intended use) displaying some
>decision making there.

Comparing C++ with Ada, we could say that Ada's "private" is rather
C++'s "protected". Then Ada has, and C++ lacks, an ability to define
subroutines with full access to members in the package body, without
any specification changing. Such subroutines could be viewed as an
equivalent to C++'s "private methods". What Ada does not have are
private data members in C++ sense. So we have:

protected in C++ <--> private in Ada
private method <--> a subroutine in the body [a FAT plus to Ada ]
private member  <--> missing [a minus]

From my point of view, Ada's model is clearer and more consitent with
separate compilation / development model. Private, in C++ sense,
things should actually never appear in the specification.

I remember, Robert Duff, proposed a way to hide everything really
*private* in the bodies. This would be IMO a right thing.

>> What I would like to have
>> 
>> 1. multiple parents;
>
>This could be useful, no doubt. But it also introduces new
>issues but I suppose I would reluctantly endorse MI if pressed
>to make a choice.

Actually I meant multiple package parents. But, yes, I wish MI as
well.

>> 3. an ability to have public read-only members with full access in the
>> private part;
>
>Yes. Even C++ lacks this. However, one could argue that you should
>always provide an "interface" to these, but from a practical level,
>I find this a big pain.

That's the crucial point. Any public declaration is (or has to be) an
interface. Moreover, I wished a full blown ADT in Ada. This would mean
that if you declare

type A is record
   X : Something
end record;

in the public part, it should to be treated as an interface, not as a
specification of a representation. So in the private part you could
say that A is actually an access type and provide Get/Set to deal with
X.

>> 4. a finer control over overridings (a vast theme).
>
>Certainly an area of discussion. The practical question is whether
>things need to be done about the present scheme of things, or not.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Need advice re package organization.

[Warren W. Gay VE3WWG]

Dmitry A. Kazakov wrote:
> On Tue, 29 Jul 2003 13:18:29 -0400, "Warren W. Gay VE3WWG"
> <ve3wwg@cogeco.ca> wrote:
>>Dmitry A. Kazakov wrote:
>>
>>>On Sun, 27 Jul 2003 18:02:08 -0400, "Warren W. Gay VE3WWG"
>>><ve3wwg@cogeco.ca> wrote:
>>>
>>>>Robert I. Eachus" <rieachus@attbi.com> wrote in message news:3F22F9E9.3040307@attbi.com...
>>>>
>>>>>Warren W. Gay VE3WWG wrote:
>>>>>
>>>>>>[As a side note, I sometimes wonder if an enhancement to the Ada0Y
>>>>>>language might be to be able to specify a limited visibility of a
>>>>>>parent package's object's internals (a la not "protected" type in
>>>>>>C++). A protected class in C++ allows derived code to mess with the
>>>>>>internals, whereas normally the parent object's elements are a
>>>>>>black box. Use of limited visibility helps to reduce code coupling.]
>>>>>
>>>>>Actually, that is what a private child package is for.  It allows you to
>>>>>move all of the "useful" internals out of a package body to a place
>>>>>where the body and all the child packages can access them.
>>>>
>>>>Actually, what I had in mind was the object visibility here (not
>>>>package visibility). When deriving from existing tagged records, there
>>>>is no way to limit the visibility of the parent object's members (a
>>>>la "protected" in C++/Java). A derived object can freely mess with any
>>>>tagged record's members, as it sees fit. Information hiding
>>>>and reduced coupling practices suggests that this is not the safest
>>>>route (best to use the existing parent object methods to mess with
>>>>the "parent members").
>>>
>>>I do not know whether there is a statistics regarding use protected
>>>vs. private, but I think that most C++ programmers just stick to
>>>public vs. not. Burden of decision is too heavy for many.
...
> Comparing C++ with Ada, we could say that Ada's "private" is rather
> C++'s "protected". Then Ada has, and C++ lacks, an ability to define
> subroutines with full access to members in the package body, without
> any specification changing. 

The problem occurs in the private child package (IMO) because
you want to derive new objects from parent tagged records. The
danger that develops is that the child package's body code may
monkey with things in the parent object that you don't want it
to (this is lack of information hiding).

However, you can fix the object visibility by making it a non
child package (just another package using the first). However,
the problem then becomes that you lose access to other types
and definitions that are in the other package's private part.

So in my mind, there still exists a short-coming OO wise
in the visibility rules for objects: it needs a way to
mark parts of a tagged object as "off limits" for the child
package, which always enjoys full visibility of the parent
package's tagged record (object).

> Such subroutines could be viewed as an
> equivalent to C++'s "private methods". What Ada does not have are
> private data members in C++ sense. So we have:
> 
> protected in C++ <--> private in Ada
> private method <--> a subroutine in the body [a FAT plus to Ada ]
> private member  <--> missing [a minus]

I think you need to add a dimension to this "chart", because
there are multiple (at least 2) views:

   1. simple client view
   2. a _normal_ child package view

   (a _private_ child's view is the same I think, but if not, this
    is a 3rd).

The problem I am trying to address, is #2. The child package sees
all, even when you don't want it to.

> From my point of view, Ada's model is clearer and more consitent with
> separate compilation / development model. Private, in C++ sense,
> things should actually never appear in the specification.

Well, one could argue that the private parts of a specification
should never be seen by clients (particularly for libraries where
body code is not provided). However, there are obviously practical
compiler reasons for including those things ;-)

One other raod a compiled language like Ada could have taken,
is to compile an intermediate file for those parts of a spec
that are required by the compiler, but should not be seen by
the client. But this has other practical problems, I suspect.

> I remember, Robert Duff, proposed a way to hide everything really
> *private* in the bodies. This would be IMO a right thing.

A child package often needs types and other constants from the
parent package, but "wants" the safety of not dabbling with the
parent object's internals.

Warren.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Need advice re package organization.

[Randy Brukardt]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:clWVa.4191$mv6.741217@news20.bellglobal.com...
> The problem occurs in the private child package (IMO) because
> you want to derive new objects from parent tagged records. The
> danger that develops is that the child package's body code may
> monkey with things in the parent object that you don't want it
> to (this is lack of information hiding).
>
> However, you can fix the object visibility by making it a non
> child package (just another package using the first). However,
> the problem then becomes that you lose access to other types
> and definitions that are in the other package's private part.
>
> So in my mind, there still exists a short-coming OO wise
> in the visibility rules for objects: it needs a way to
> mark parts of a tagged object as "off limits" for the child
> package, which always enjoys full visibility of the parent
> package's tagged record (object).

You can do this by deferring the contents of the tagged type to the body:

     type My_Type_Contents;
     type My_Type_Contents_Access is access all My_Type_Contents;
     type My_Type is tagged record
          Contents : My_Type_Contents_Access;
     end record;

Then no child can see the contents. Claw uses this technique in some cases.
The body contains the full declaration of My_Type_Contents.

This technique works best when the tagged type is Controlled (since the vast
majority of tagged types ought to be controlled, this is not a real
restriction). Then the Initialize routine can allocate the contents, and the
Finalize can free it. The only remaining danger would be someone assigning a
Null into the Contents access, which is a lot less likely than fiddling with
components.

               Randy.

Re: Need advice re package organization.

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
> news:clWVa.4191$mv6.741217@news20.bellglobal.com...
> 
>>The problem occurs in the private child package (IMO) because
>>you want to derive new objects from parent tagged records. The
>>danger that develops is that the child package's body code may
>>monkey with things in the parent object that you don't want it
>>to (this is lack of information hiding).
>>
>>However, you can fix the object visibility by making it a non
>>child package (just another package using the first). However,
>>the problem then becomes that you lose access to other types
>>and definitions that are in the other package's private part.
>>
>>So in my mind, there still exists a short-coming OO wise
>>in the visibility rules for objects: it needs a way to
>>mark parts of a tagged object as "off limits" for the child
>>package, which always enjoys full visibility of the parent
>>package's tagged record (object).
> 
> You can do this by deferring the contents of the tagged type to the body:
> 
>      type My_Type_Contents;
>      type My_Type_Contents_Access is access all My_Type_Contents;
>      type My_Type is tagged record
>           Contents : My_Type_Contents_Access;
>      end record;
> 
> Then no child can see the contents. Claw uses this technique in some cases.
> The body contains the full declaration of My_Type_Contents.

That appears to accomplish the end result. However, this
design pays a price in allocating and freeing an additional
[sub]object.

For some designs this would be acceptable, but not where
you have many instances of the object, where the price
of allocate/free is too heavy.

So I think my point still stands: you really cannot "properly"
accomplish what I have set out to do, although you have
illustrated a work-around.

> This technique works best when the tagged type is Controlled (since the vast
> majority of tagged types ought to be controlled, this is not a real
> restriction). Then the Initialize routine can allocate the contents, and the
> Finalize can free it. The only remaining danger would be someone assigning a
> Null into the Contents access, which is a lot less likely than fiddling with
> components.
> 
>                Randy.

Agreed that the risk is lower, but it still exists if you place
the objects (from a library) in the hands of a user.  If you
are supporting that library, this increases risk of servicing
calls that should not be your responsibility.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Need advice re package organization.

[Randy Brukardt]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:7DbWa.1370$qN3.183518@news20.bellglobal.com...

> Agreed that the risk is lower, but it still exists if you place
> the objects (from a library) in the hands of a user.  If you
> are supporting that library, this increases risk of servicing
> calls that should not be your responsibility.

Why would a user be creating child units of the library? That seems dubious
in the first place.

Taking the example of Claw, if you declared a package like
Claw.Dialog.Foobar, you could get access to a lot of Claw internals. But the
only reason for a user to declare such a package is that they needed such
access (hopefully, they're building a new reusable component). In which
case, more hiding is not going to help.

Certainly, anyone who just "with"s Claw.Dialog is not going to get any
private stuff. And, in our experience with a large library given to the
general public, people aren't declaring (grand)children of Claw just so they
can fiddle around with stuff that they don't need. Especially as we spend a
lot of effort keeping the public interfaces stable, but we certainly say
nothing about private stuff. So I view this as a non-problem, especially as
techniques exist to avoid it.

If your users are randomly declaring children, their project has serious
project management problems. It's unlikely that the language can fix these
(or should try).

                Randy.

Re: Need advice re package organization.

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
> news:7DbWa.1370$qN3.183518@news20.bellglobal.com...
> 
>>Agreed that the risk is lower, but it still exists if you place
>>the objects (from a library) in the hands of a user.  If you
>>are supporting that library, this increases risk of servicing
>>calls that should not be your responsibility.
> 
> Why would a user be creating child units of the library? That seems dubious
> in the first place.

You're right -- it was a brain fart.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Need advice re package organization.

[Robert I. Eachus]

Warren W. Gay VE3WWG wrote:

> That appears to accomplish the end result. However, this
> design pays a price in allocating and freeing an additional
> [sub]object.
> 
> For some designs this would be acceptable, but not where
> you have many instances of the object, where the price
> of allocate/free is too heavy.

No, remember the access all.  The values of the actual objects need not 
be on the heap, or could be on the heap but not individually allocated 
For example, I have a package that implements sparse matrices, as linked 
lists of rows and columns. Very messy and the allocation overhead might 
make it useless if the package didn't just grab chunks of heap and 
manage them as 10,000 separate nodes.  This way, creating an array takes 
time proportional to the number of non-zero elements, but much faster 
than allocating each element, and freeing an array takes time 
proportional to the number of non-zero columns.

-- 
"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: Need advice re package organization.

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:
> Warren W. Gay VE3WWG wrote:
> 
>> That appears to accomplish the end result. However, this
>> design pays a price in allocating and freeing an additional
>> [sub]object.
>>
>> For some designs this would be acceptable, but not where
>> you have many instances of the object, where the price
>> of allocate/free is too heavy.
> 
> 
> No, remember the access all.  The values of the actual objects need not 
> be on the heap, or could be on the heap but not individually allocated 
> For example, I have a package that implements sparse matrices, as linked 
> lists of rows and columns. Very messy and the allocation overhead might 
> make it useless if the package didn't just grab chunks of heap and 
> manage them as 10,000 separate nodes.  This way, creating an array takes 
> time proportional to the number of non-zero elements, but much faster 
> than allocating each element, and freeing an array takes time 
> proportional to the number of non-zero columns.

And that is fine if you are instantiating all of those objects in
one fell swoop, or managing a pool of such. But _all_ of these
are "work-arounds" to the original problem. All of these work
arounds take you away from the original problem at hand. Others
will also argue that other environments do not require these
work-arounds, either.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Need advice re package organization.

[Matthew Heaney]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:clWVa.4191$mv6.741217@news20.bellglobal.com...
>
> The problem occurs in the private child package (IMO) because
> you want to derive new objects from parent tagged records. The
> danger that develops is that the child package's body code may
> monkey with things in the parent object that you don't want it
> to (this is lack of information hiding).

That the private part of the parent package is visible to (the private part
of) a child is a feature of the language.

Yes, there is a "lack of information hiding," but the syntax of the language
is designed so that it's obvious who has access to the private information,
e.g. if I see P.C, I know that C has visibility to P.

This is a consequence of the fact that visibility in Ada is controlled by
the module relationship.  One issue in C++ is that if I have:

class B
{
public:
   virtual ~B();
protected:
   secret_t m_secret;
};

then yes, this says that data member m_secret is visible to classes that
derive from B, but there's nothing that identifies which classes those are.
If I see a class D, there's nothing to tell me that D derives from B (unless
you look at D's declaration, of course).

This is why I usually name derived classes by tacking the derived name onto
the base class name, e,g

class Presentation { /* ... */ };
class PresentationAVI : public Presentation { /* ... */ };
etc

class Stream { /* ... */ };
class StreamAVI : public Stream { /* ... */ };
class StreamWAV : public Stream { /* ... */ };
etc.

At least in Ada, if I have one type that derives from another, e.g.

package P is
   type T is tagged ...;
...
end P;

package P.C is
   type NT is new T with ...;
...
end P.C;

then at least when I see P.C.NT, I know immediately that C can see the
private part of P.

So I don't agree that one should that a parent package should try to "hide"
stuff from a child.  The set of modules that have visibility to the private
part of P (and hence, that need to be consulted if there is a change) is
bounded, and clearly demarcated.  In the typical case the members of a
package hierarchy (the "subsystem") would be kept together in a project,
probably in the same directory, and maintained by a single person.

Re: Need advice re package organization.

[Warren W. Gay VE3WWG]

Matthew Heaney wrote:

> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
> news:clWVa.4191$mv6.741217@news20.bellglobal.com...
> 
>>The problem occurs in the private child package (IMO) because
>>you want to derive new objects from parent tagged records. The
>>danger that develops is that the child package's body code may
>>monkey with things in the parent object that you don't want it
>>to (this is lack of information hiding).
> 
> That the private part of the parent package is visible to (the private part
> of) a child is a feature of the language.

Yes, I know :-)

> Yes, there is a "lack of information hiding," but the syntax of the language
> is designed so that it's obvious who has access to the private information,
> e.g. if I see P.C, I know that C has visibility to P.

How does the "obviousness" prevent developers of the body from
messing up the parent object's internals? Maybe there is an
accidental reference to like-named members or methods?

> This is a consequence of the fact that visibility in Ada is controlled by
> the module relationship.  One issue in C++ is that if I have:

I understand the issue, and I myself prefer Ada95 to any
computer language, but folks, let's be honest about the
weakness here ;-)

> class B
> {
> public:
>    virtual ~B();
> protected:
>    secret_t m_secret;
> };
> 
> then yes, this says that data member m_secret is visible to classes that
> derive from B, but there's nothing that identifies which classes those are.
> If I see a class D, there's nothing to tell me that D derives from B (unless
> you look at D's declaration, of course).

Of course.

> This is why I usually name derived classes by tacking the derived name onto
> the base class name, e,g
> 
> class Presentation { /* ... */ };
> class PresentationAVI : public Presentation { /* ... */ };
> etc
> 
> class Stream { /* ... */ };
> class StreamAVI : public Stream { /* ... */ };
> class StreamWAV : public Stream { /* ... */ };
> etc.

Well, it works for you and that is fine. I see this as bending
the language to suit your needs, and clearly C++ has a weakness
in this respect.

> At least in Ada, if I have one type that derives from another, e.g.
> 
> package P is
>    type T is tagged ...;
> ....
> end P;
> 
> package P.C is
>    type NT is new T with ...;
> ....
> end P.C;
> 
> then at least when I see P.C.NT, I know immediately that C can see the
> private part of P.

Yes, but you've achieved that simplicity at the expense of
functionality. Some of us would rather have the functionality
as a tradeoff (and that is what we're talking about here, unless
a proposed solution addresses both issues).

This is the basis of much of the MI discussion. Some like the
simplicity of not having it, while others insist on having the
MI supported.

> So I don't agree that one should that a parent package should try to "hide"
> stuff from a child. 

You are saying you don't support it because you favour the
simplicity of the approach. That is different than saying
that you don't agree that information hiding here should
be supported (maybe clarification of your position is
required here?)

But I would expect that you would still favour the use of
information hiding, when it was appropriate. I would expect
that if your position (simplicity) was achieved, then you
would not have an objection to the point that I am raising.

 > The set of modules that have visibility to the private
> part of P (and hence, that need to be consulted if there is a change) is
> bounded, and clearly demarcated.  In the typical case the members of a
> package hierarchy (the "subsystem") would be kept together in a project,
> probably in the same directory, and maintained by a single person.

Again, you are evaluating the point on the basis of how
easy things are "identified". But the real point of this
discussion is that a object visibility control is lacking.

PROTECTED ACCESS:

In fact, the other side of the OO coin is also true: namely
in Ada95, you can only have public or private members and
primitives (without breaking the object into multiple
derivations). At the very least, this is a pain.

Irregardless, there is _NO_ way whatsoever to identify
Ada95 OO members/primitives as "protected" (ie. accessable
by derived code, but not to the end clients of the object).

Is this a show stopper? Well, no. But it has been long
recognized in the software industry that information hiding
promotes safety.  All I am saying, is that Ada95 seems to
lack this feature and it should perhaps be more vigorously
discussed ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Need advice re package organization.

[Robert I. Eachus]

Warren W. Gay VE3WWG wrote:

> Is this a show stopper? Well, no. But it has been long
> recognized in the software industry that information hiding
> promotes safety.  All I am saying, is that Ada95 seems to
> lack this feature and it should perhaps be more vigorously
> discussed ;-)


If I understand you correctly, what you would like is a syntax for 
saying that the components of an object can not be modified outside the 
package hierarchy, but can be read.

I can imagine a syntax for doing this, but it wouldn't add any safety. 
(If nothing else a user could use Unchecked_Conversion to declare a 
matching type.)

But the real problem is what I call unchecked perversion.  I coined the 
name the first time I saw a package specification that contained an 
instance of Unchecked_Conversion.  If a conversion between two types is 
made public like this, then any code in the entire project can depend on 
the equivalence, and changing the representation of the type may cause 
random errors elsewhere in the program.

In the case where I first ran into it, it was several conversions 
between Integer and an access type.  Of course, when we went to port the 
code, some of the access types by default would have used fat pointers. 
  We could force the types to use integer-sized pointers, but it was a 
pain.  The several weeks of work to fix the code would have been a 
bigger pain.  (If I were in the compiler business, I would have a very 
nasty warning when s package spec contained a visible instance of 
Unchecked_Conversion.)

So the advantage of supplying the inquiry functions is that you can 
later change the data layout, add new components, change 
representations, or even make some values which were originally explicit 
virtual.  I think a much better solution to your problem is a tool that 
automatically generates the inquiry functions from the type declaration. 
  Sounds like a good candidate for adding to the Emacs ada-mode.

-- 
"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: Need advice re package organization.

[Chad R. Meiners]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:3F299920.9070603@attbi.com...
> So the advantage of supplying the inquiry functions is that you can
> later change the data layout, add new components, change
> representations, or even make some values which were originally explicit
> virtual.  I think a much better solution to your problem is a tool that
> automatically generates the inquiry functions from the type declaration.
>   Sounds like a good candidate for adding to the Emacs ada-mode.

Or a type builder wizard in GPS! ;-)

Re: Need advice re package organization.

[Stephen Leake]

"Chad R. Meiners" <crmeiners@hotmail.com> writes:

> "Robert I. Eachus" <rieachus@attbi.com> wrote in message
> news:3F299920.9070603@attbi.com...
> > So the advantage of supplying the inquiry functions is that you can
> > later change the data layout, add new components, change
> > representations, or even make some values which were originally explicit
> > virtual.  I think a much better solution to your problem is a tool that
> > automatically generates the inquiry functions from the type declaration.
> >   Sounds like a good candidate for adding to the Emacs ada-mode.
> 
> Or a type builder wizard in GPS! ;-)

The core tool is probably best written in Ada using ASIS; it would be
somewhat similar to Auto_Text_IO. Emacs ada-mode and GPS could provide
user interfaces to the tool, but it would really need to be run as
part of the build process (from a makefile).

Hmm. That would imply that the inquiry functions where in a child
package; no problem if they don't need to be dispatching.

-- 
-- Stephe

Re: Need advice re package organization.

[Robert I. Eachus]

Stephen Leake wrote:

> The core tool is probably best written in Ada using ASIS; it would be
> somewhat similar to Auto_Text_IO. Emacs ada-mode and GPS could provide
> user interfaces to the tool, but it would really need to be run as
> part of the build process (from a makefile).
> 
> Hmm. That would imply that the inquiry functions where in a child
> package; no problem if they don't need to be dispatching.

You made me think for a while, but I came back to my original idea.  The 
problem with automatically generated non-dispatching inquiry functions 
would be that, when overloading occurs, the user is going to be really 
upset by the lack of a class-wide operation.  The easiest way to explain 
it is that inserting a type conversion to a specific type would get the 
code to compile, but sometimes that conversion would raise an exception 
at run-time.  So, I don't see problems occuring frequently, if your 
design is the more typical bushy Ada style derivation tree, but I see 
them as nasty when they arise.

So I think it is much better to have the inquiry functions in the 
package which declares the type, which seems to rule out ASIS as a 
generator, unless the ASIS package generated as set of inquiry functions 
for the type and all types derived from it.  This might require multiple 
child packages to be generated.  A typical inquiry function might look like:

    function Selling_Price (Stock_Item'Class) return Dollars;

And the ASIS tool would have to generate explicit dispatching code in 
the body, with the appropriate with clauses.

I think that is probably overkill for inquiry functions, but it might 
work well for things like creating a model-view-controller environment 
with on screen display for things like bench testing subsystems.  The 
test environment could automatically be generated from the software and 
a test script.  (The test script would provide the inputs and a list of 
the objects to be displayed.)


-- 
"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: Need advice re package organization.

[Stephen Leake]

"Robert I. Eachus" <rieachus@attbi.com> writes:

> Stephen Leake wrote:
> 
> > The core tool is probably best written in Ada using ASIS; it would be
> > somewhat similar to Auto_Text_IO. Emacs ada-mode and GPS could provide
> > user interfaces to the tool, but it would really need to be run as
> > part of the build process (from a makefile).
> > Hmm. That would imply that the inquiry functions where in a child
> > package; no problem if they don't need to be dispatching.
> 
> You made me think for a while, but I came back to my original idea.
> The problem with automatically generated non-dispatching inquiry
> functions would be that, when overloading occurs, the user is going to
> be really upset by the lack of a class-wide operation.  The easiest
> way to explain it is that inserting a type conversion to a specific
> type would get the code to compile, but sometimes that conversion
> would raise an exception at run-time.  So, I don't see problems
> occuring frequently, if your design is the more typical bushy Ada
> style derivation tree, but I see them as nasty when they arise.
> 
> So I think it is much better to have the inquiry functions in the
> package which declares the type, which seems to rule out ASIS as a
> generator, unless the ASIS package generated as set of inquiry
> functions for the type and all types derived from it.  

I was a bit hasty. It's somewhat simpler to have ASIS generate a child
package, but it can also provide a single package with the type and
the inquiry functions. You just use it as a preprocessor. You write a
"template" package that has the type but no inquiry functions, and the
tool produces a new package that has both. It's up to the makefile to
keep things straight.

It would be nice if we could extend gnatmake to know about arbitrary
preprocessors :).

> This might require multiple child packages to be generated. A
> typical inquiry function might look like:
> 
>     function Selling_Price (Stock_Item'Class) return Dollars;
> 
> And the ASIS tool would have to generate explicit dispatching code in
> the body, with the appropriate with clauses.

Yech :).

> I think that is probably overkill for inquiry functions, but it
> might work well for things like creating a model-view-controller
> environment with on screen display for things like bench testing
> subsystems. The test environment could automatically be generated
> from the software and a test script. (The test script would provide
> the inputs and a list of the objects to be displayed.)

People keep proposing these "automatically generated test
environments". I find them un-helpful; the hard work is in the input
data, and I find that Ada is an excellent language for generating input
data; I don't want to use some weak "script" language. It is also easy
to write a test environment in Ada. Maybe for GUI tools, things are
different. I have some GUI test stuff in Windex, and it is a
significantly different style than my other tests. But even there, the
large majority of the code is about generating the right input events
(positioning the mouse, clicking it, generating key events); the "test
environment" is pretty thin.
> 
> 
> -- 
> "As far as I'm concerned, war always means failure." -- Jacques
> Chirac, President of France
> "As far as France is concerned, you're right." -- Rush Limbaugh
> 

-- 
-- Stephe

Re: Need advice re package organization.

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:

> Warren W. Gay VE3WWG wrote:
> 
>> Is this a show stopper? Well, no. But it has been long
>> recognized in the software industry that information hiding
>> promotes safety.  All I am saying, is that Ada95 seems to
>> lack this feature and it should perhaps be more vigorously
>> discussed ;-)
> 
> If I understand you correctly, what you would like is a syntax for 
> saying that the components of an object can not be modified outside the 
> package hierarchy, but can be read.

I am basically looking for private and protected type class
qualifiers a al (dare I say it), C++.  The problem is that
the entire tagged record (object) is completely visible to
child package code, at times when I wish it wasn't (for
safety's sake). Its a small point, but I only raised it
for general discussion as a minor weakness.

> I can imagine a syntax for doing this, but it wouldn't add any safety. 
> (If nothing else a user could use Unchecked_Conversion to declare a 
> matching type.)

There is no protection for those that are determined to work
around it. There are many ways to defeat protections, and another
way is to break into C code and do what you will. But I am not
worried about that.

In the child package case, I am the one doing the programming (if I
am the author of the parent package). However, what sometimes happens
is that the child package derives from a parent package object, but
still enjoys full visibility of the base type's innards. For some
objects, this is highly undesireable, and leads to unwanted
coupling (leading to unwanted mistakes of reference).
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Need advice re package organization.

[Dmitry A. Kazakov]

On Wed, 30 Jul 2003 17:00:00 -0400, "Warren W. Gay VE3WWG"
<ve3wwg@cogeco.ca> wrote:

>Dmitry A. Kazakov wrote:

>> Such subroutines could be viewed as an
>> equivalent to C++'s "private methods". What Ada does not have are
>> private data members in C++ sense. So we have:
>> 
>> protected in C++ <--> private in Ada
>> private method <--> a subroutine in the body [a FAT plus to Ada ]
>> private member  <--> missing [a minus]
>
>I think you need to add a dimension to this "chart", because
>there are multiple (at least 2) views:
>
>   1. simple client view
>   2. a _normal_ child package view
>
>   (a _private_ child's view is the same I think, but if not, this
>    is a 3rd).
>
>The problem I am trying to address, is #2. The child package sees
>all, even when you don't want it to.

But if you do not want to see private things, then the package should
not be a child.

-----------------------------------------
However I should admit that there is a problem, not only in Ada, but
it other OO languages too. It is a "philosophic" problem:

"When implemening a method should I favour private or public
interface?"

Note that this problem exists even for a single package / class. Let I
have a public Getter for some hidden member, should I use it instead
of accessing the member directly implementing some other method?

There is no definite answer to this, but in what a language (Ada)
could help is in a clear separation of both.

As a raw idea, one could have public and private parts of the package
body. Or alternatively, one could have up to two bodies, private and
public:

package [private] body A is
   -- I see everything
   -- All dirty stuff goes here
end A;

package public body A is
   -- I see only the public part
   -- I need not review this body as long as the public part
   -- remains unchanged
end A;

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Need advice re package organization.

[Warren W. Gay VE3WWG]

Dmitry A. Kazakov wrote:

> On Wed, 30 Jul 2003 17:00:00 -0400, "Warren W. Gay VE3WWG"
> <ve3wwg@cogeco.ca> wrote:
>>Dmitry A. Kazakov wrote:
> 
>>>Such subroutines could be viewed as an
>>>equivalent to C++'s "private methods". What Ada does not have are
>>>private data members in C++ sense. So we have:
>>>
>>>protected in C++ <--> private in Ada
>>>private method <--> a subroutine in the body [a FAT plus to Ada ]
>>>private member  <--> missing [a minus]
>>
>>I think you need to add a dimension to this "chart", because
>>there are multiple (at least 2) views:
>>
>>  1. simple client view
>>  2. a _normal_ child package view
>>
>>  (a _private_ child's view is the same I think, but if not, this
>>   is a 3rd).
>>
>>The problem I am trying to address, is #2. The child package sees
>>all, even when you don't want it to.
> 
> But if you do not want to see private things, then the package should
> not be a child.

You are missing the point. If the package is not a child package,
then this new package loses all access to the other private
types declared in the private section. Sometimes you need to have
things both ways.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Need advice re package organization.

[Randy Brukardt]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:AVbWa.1379$qN3.184689@news20.bellglobal.com...
> > But if you do not want to see private things, then the package should
> > not be a child.
>
> You are missing the point. If the package is not a child package,
> then this new package loses all access to the other private
> types declared in the private section. Sometimes you need to have
> things both ways.

That sounds like a very muddled design. Previously you said:

> Irregardless, there is _NO_ way whatsoever to identify
> Ada95 OO members/primitives as "protected" (ie. accessable
> by derived code, but not to the end clients of the object).

Which is false: The derived code goes in children (if they need the
visibility), the end clients do not. If your end clients are in children,
you've got design problems.

What you're asking for is a fine-grained visibility control that does not
exist anywhere in Ada. For instance, when you say "with", you get the whole
package; there is no option to just get part of it. When you say "use", you
get the whole package; there is no option to just get individual items.

Some have claimed this is a fault, but in any case you'd have a very
different language if you had those sorts of capabilities. One of the
advantages of the current scheme is that it works very well for
programming-in-the-large: a change to a distant unit can only change units
in which it is directly referenced.

We've found in working on "limited with" that this property is a lot harder
to maintain if you have views of the same entity with different properties
that can clash (if you have a diamond-shaped with pattern). This is a
property that we should not be willing to give up for Ada.

Anyway, I think you will have to make a complete proposal so we can tear it
to shreds. :-) Claiming that there is some lack of visibility control
without showing how that control could be defined and would be used in
practice is not very compelling.

                         Randy.

Re: Need advice re package organization.

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
> news:AVbWa.1379$qN3.184689@news20.bellglobal.com...
> 
>>>But if you do not want to see private things, then the package should
>>>not be a child.
>>
>>You are missing the point. If the package is not a child package,
>>then this new package loses all access to the other private
>>types declared in the private section. Sometimes you need to have
>>things both ways.
> 
> That sounds like a very muddled design. Previously you said:
> 
>>Irregardless, there is _NO_ way whatsoever to identify
>>Ada95 OO members/primitives as "protected" (ie. accessable
>>by derived code, but not to the end clients of the object).
> 
> Which is false: The derived code goes in children (if they need the
> visibility), the end clients do not. If your end clients are in children,
> you've got design problems.

I think you're mis-reading me here.

I am concerned with being able to write a child package which
derives a new type (object) from the parent package. Because
the child package enjoys full visibility (a good thing for the
parent's private types I need), this child package _ALSO_
has full visibility to the tagged objects defined in the private
part of the parent (this is normally a good thing).

BUT, I want, in many cases, to restrict access to members/primitives
of the parent tagged type.

Why is this so difficult to describe/understand? Let's use C++
terms then:

Take the C++ concept of a "private" member, and apply it to a
child package, but, having the child package not be able to
tamper with private members (ie. these members are not public,
and not protected using C++ terms).

Conversely:

Take a C++ class member, declare members "protected" so only deriving
code has visibility; but not the end client code (application code).

> What you're asking for is a fine-grained visibility control that does not
> exist anywhere in Ada. 

YES!  And precisely my point.  It _does_ not exist in Ada.

> Some have claimed this is a fault, but in any case you'd have a very
> different language if you had those sorts of capabilities. 

All I ever was suggesting was that some further discussion
might be worthwhile, particularly in light of 200y changes.

> One of the
> advantages of the current scheme is that it works very well for
> programming-in-the-large: a change to a distant unit can only change units
> in which it is directly referenced.

I fail to see how the implementation of "protected" would change
this "nature" for programming in the large.

> We've found in working on "limited with" that this property is a lot harder
> to maintain if you have views of the same entity with different properties
> that can clash (if you have a diamond-shaped with pattern). This is a
> property that we should not be willing to give up for Ada.

I was never proposing, nor interested in selective uses of private
parts of a package. I am only speaking of tagged record views here,
but it has application to child packages, because of their special
status.

> Anyway, I think you will have to make a complete proposal so we can tear it
> to shreds. :-) Claiming that there is some lack of visibility control
> without showing how that control could be defined and would be used in
> practice is not very compelling.
> 
>                          Randy.

Randy, I don't think you're being entirely fair about this discussion.

We're talking about protected access of classes (C++). I am not saying
Ada has to have it, but merely pointing out that I find it "missing"
WRT to having used C++ in a previous life. IOW, I find a need/wish
for it, on the principle that "information hiding" is safer, which is
what Ada95 already makes good use of. Claiming that the current Ada model
is without need for improvement, is IMO, a bit biased.  It suggests
that the current visibility model has already achieved perfection.

But, if it never came to pass, I will still sleep just as well. I only
made it a point of discussion. B-)
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Need advice re package organization.

[Randy Brukardt]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:7GfWa.5186$mv6.907516@news20.bellglobal.com...
> Randy Brukardt wrote:
> > Which is false: The derived code goes in children (if they need the
> > visibility), the end clients do not. If your end clients are in
children,
> > you've got design problems.
>
> I think you're mis-reading me here.

Certainly possible.

> I am concerned with being able to write a child package which
> derives a new type (object) from the parent package. Because
> the child package enjoys full visibility (a good thing for the
> parent's private types I need), this child package _ALSO_
> has full visibility to the tagged objects defined in the private
> part of the parent (this is normally a good thing).

OK. Let me understand you. This translates to "I want to see private
things".

> BUT, I want, in many cases, to restrict access to members/primitives
> of the parent tagged type.

This translates to "I do not want to see private things." Does it make it
clear why I'm confused? :-)

You said that you need visibility on the parent's private types, but you
clearly don't need to be a child to have that. And if you do need visibility
on items in the private part, then you need that. Finally, if there is stuff
that you don't want anyone to have visibility on, you put item into the
body. So where's the problem?

> Why is this so difficult to describe/understand? Let's use C++ terms then:

Sorry, I don't know C++ well enough to understand the detailed meaning of
these terms. I'd like to see an actual Ada proposal, which I can try to
understand.

> > What you're asking for is a fine-grained visibility control that does
not
> > exist anywhere in Ada.
>
> YES!  And precisely my point.  It _does_ not exist in Ada.
>
> > Some have claimed this is a fault, but in any case you'd have a very
> > different language if you had those sorts of capabilities.
>
> All I ever was suggesting was that some further discussion
> might be worthwhile, particularly in light of 200y changes.

I don't believe that it is possible to graft fine-grained visibility control
into Ada. It's been tried before (during the Ada 9x process) and it didn't
work out then.

It would make perfect sense for an Ada-like language to have this sort of
control, but not Ada itself (because of compatibility issues).

> > One of the advantages of the current scheme is that it works very well
for
> > programming-in-the-large: a change to a distant unit can only change
units
> > in which it is directly referenced.
>
> I fail to see how the implementation of "protected" would change
> this "nature" for programming in the large.
>
> > We've found in working on "limited with" that this property is a lot
harder
> > to maintain if you have views of the same entity with different
properties
> > that can clash (if you have a diamond-shaped with pattern). This is a
> > property that we should not be willing to give up for Ada.
>
> I was never proposing, nor interested in selective uses of private
> parts of a package. I am only speaking of tagged record views here,
> but it has application to child packages, because of their special status.

I still have no clear idea what you have in mind. I'm leary of saying that
we need fine-grained visibility control, but only of "record views"
(whatever that is). Why does your problem not apply to other declarations
(subprograms and subtypes) as well?

> > Anyway, I think you will have to make a complete proposal so we can tear
it
> > to shreds. :-) Claiming that there is some lack of visibility control
> > without showing how that control could be defined and would be used in
> > practice is not very compelling.
> >
> Randy, I don't think you're being entirely fair about this discussion.
>
> We're talking about protected access of classes (C++).

As I said above, I don't know C++ well enough to know exactly what it is
that you are proposing. And in any case, Ada is not C++. Please describe
what you want in Ada terms, with Ada syntax.

> I am not saying
> Ada has to have it, but merely pointing out that I find it "missing"
> WRT to having used C++ in a previous life. IOW, I find a need/wish
> for it, on the principle that "information hiding" is safer, which is
> what Ada95 already makes good use of. Claiming that the current Ada model
> is without need for improvement, is IMO, a bit biased.  It suggests
> that the current visibility model has already achieved perfection.

No, the visibility model is far from perfect. The problem is that it has
resisted most attempts to change it, because it is very hard to come up with
a compatible change that works in ALL cases. A lot of ideas make perfect
sense in the normal case, but come to grief on bizarre corner cases that no
one really cares about (but have to work).

Having a lot of experience with that, I tend to resist making another
attempt, particularly without a clear justification. That IS my bias.

> But, if it never came to pass, I will still sleep just as well. I only
> made it a point of discussion. B-)

Well, it does not hurt to bring up ideas. I just would like to understand
what they are well enough to understand why the language doesn't provide it
already.

                    Randy.

Re: Need advice re package organization.

[Stephen Leake]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
> news:7GfWa.5186$mv6.907516@news20.bellglobal.com...
> <snip>
> >
> > We're talking about protected access of classes (C++).
> 
> As I said above, I don't know C++ well enough to know exactly what it is
> that you are proposing. And in any case, Ada is not C++. Please describe
> what you want in Ada terms, with Ada syntax.

Perhaps I can help, since I beleive I do know C++ and Ada well enough
:).

The C++ notions of public, protected, and private member functions do
not map one-to-one into Ada, but they map fairly well according to the
following scheme (data members below):
       
C++         Ada
public      public part of package spec
protected   private part of package spec
private     package body

C++ can make the same distinctions among data members of a record
type. For example:

class Foo
{
public:
   int A;
protected:
   int B;
private:
   int C;
}

A is visible to all children and clients of Foo; B is visible to
children of Foo; C is only visible within Foo.

To achieve the same visibility in Ada, we need to break up the record
type:

package Foo_Package is

   type Protected_Foo is private;

   type Foo is record
      A : Integer;
      Protected_Stuff : Protected_Foo;
   end record;

private
   type Private_Foo;
   type Private_Foo_Access is access Private_Foo;

   type Protected_Foo is record
      B : integer;
      Private_Stuff : Private_Foo_Access;
   end record;
end Foo_Package;

package body Foo_Package is
   type Private_Foo is record
       C : Integer;
   end type;
   
end Foo_Package;

If you are comming from a C++ background, the Ada approach seems
contorted. From an Ada point of view, the C++ approach seems
simplistic :).


I believe I have seen proposals that allow a single Ada record to have
public and private parts, something like:

package Foo_Package is

   type Foo is record
      A : Integer;
   end record with private;

private

   type Foo is record with private
      B : integer;
   end record;

end Foo_Package;

But that only achieves the C++ protected visibility, not the private.

-- 
-- Stephe

Re: Need advice re package organization.

[Randy Brukardt]

"Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
news:uu191kqqd.fsf@nasa.gov...
> The C++ notions of public, protected, and private member functions do
> not map one-to-one into Ada, but they map fairly well according to the
> following scheme (data members below):
>
> C++         Ada
> public      public part of package spec
> protected   private part of package spec
> private     package body

Thanks.

It doesn't seem particularly valuable to me; the extra type(s) needed to
achieve this are mildly annoying but hardly in the class of critical flaw.
And this was an issue that the Ada 9X design team discussed, and it was
explicitly decided not to address it (in favor of addressing other, more
critical, needs).

BTW, depended on the details, you could derive the visible type from the
'protected' one, so that you inherit the operations for the protected one.

                    Randy.

Re: Need advice re package organization.

[Stephen Leake]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
> news:uu191kqqd.fsf@nasa.gov...
> > The C++ notions of public, protected, and private member functions do
> > not map one-to-one into Ada, but they map fairly well according to the
> > following scheme (data members below):
> >
> > C++         Ada
> > public      public part of package spec
> > protected   private part of package spec
> > private     package body
> 
> Thanks.

You're welcome. It's not often I get to provide a service like this :).

> It doesn't seem particularly valuable to me; the extra type(s)
> needed to achieve this are mildly annoying but hardly in the class
> of critical flaw. 

I agree. I think the C++ approach leads to more confusion than it is worth.


-- 
-- Stephe

Re: Need advice re package organization.

[Richard Riehle]

"Dmitry A. Kazakov" wrote:

> However I should admit that there is a problem, not only in Ada, but
> it other OO languages too. It is a "philosophic" problem:

May I suggest you take a look at the Modula-3 approach to this problem.
It is quite a nice way to deal with it.

Not that I am suggesting Modula-3 since that language has its own
problems that make it unsuitable for safety-critical software.

There is no perfect language.  No, Hyman, even C++ is not a perfect
programming language -- any more than Ada or Eiffel are.

Richard Riehle

Re: Need advice re package organization.

[Hyman Rosen]

Richard Riehle wrote:
> There is no perfect language.  No, Hyman, even C++ is not a perfect
> programming language -- any more than Ada or Eiffel are.

C++ must be the least perfect good programming language in existence.
Get me automatic instantiation and partial specialization in Ada, and
I may yet switch :-) With OpenToken and Charles, it's tempting...

Re: Need advice re package organization.

[Dmitry A. Kazakov]

On Mon, 04 Aug 2003 20:36:12 -0700, Richard Riehle
<richard@adaworks.com> wrote:

>"Dmitry A. Kazakov" wrote:
>
>> However I should admit that there is a problem, not only in Ada, but
>> it other OO languages too. It is a "philosophic" problem:
>
>May I suggest you take a look at the Modula-3 approach to this problem.
>It is quite a nice way to deal with it.
>
>Not that I am suggesting Modula-3 since that language has its own
>problems that make it unsuitable for safety-critical software.

I played with Modula-2 (it was long time ago and was actually caused
by unavailability of an Ada compiler for that platform), but I somehow
missed Modula-3. Probably I'll take a look at it. Thanks.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Need advice re package organization.

[Nick Roberts]

"Bobby D. Bryant" <bdbryant@mail.utexas.edu> wrote in message
news:pan.2003.07.26.13.08.25.810488@mail.utexas.edu...

> Most of my work with Ada has involved either smallish
> programs or simple self-contained library units where a
> good package organization was obvious, but now I'm
> doing something with several layers of interrelated parts
> and I'd like to get some experienced advice on how to
> organize my components into packages.
> ...
> 3) Create a lean parent package and implement each
> object in a separate child package, "with"ing the others
> as needed.

In situations like this, I tend to aim for lots of relatively small packages
and subunits.

Generally, I'll have one major type, together with its auxiliary types, and
the associated operations in one package. Sometimes I'll have or three quite
closely coupled types in one package; I'm generally convinced a set of types
are closely coupled if there are a lot of operations with a mixture of them
as parameters. I like to hive off big bodies (ooer :-) into subunits.

At first, it can seem like a right pain doing this, since it is taxing
thinking up names of all packages, time consuming creating all the separate
files, with their headers and paraphernalia, and so on. In addition, you
tend to have to use long-winded extended names a great deal, and you also
tend to find that you need to re-organise things half way through, which
means lots more creating of files and shuffling about of code.

However, I have found through (very ;-) hard experience that as I start
getting deeply into a project of any size, my brain starts turning into
jelly, and I find it increasingly hard to keep track of what is where. It is
then that having a well-organised package and subunit hierarchy pays off in
a big way. When you see a call to the procedure Blurg.Boogle.Watcha.Gerrof
and you want to look at its body, you know all you have to do is call up
"blurg-boogle-watcha-gerrof.adb" and there it is; no searching through reams
of code in a giant package body.

Hope this is of some help. Best of luck!

--
Nick Roberts
Jabber: debater@charente.de [ICQ: 159718630]