Re: Need advice re package organization.

[Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>]

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