Re: Need advice re package organization.

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

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