Re: Mut. Recurs. in Ada9X w/o Breaking Encaps.? (LONG)

[mab@dst17.wdl.loral.com (Mark A Biggar)]

In article <Cwyzx4.H3K@irvine.com> adam@irvine.com (Adam Beneschan) writes:
>I assume that the examples given work correctly.  I assume also that
>they satisfy the really important requirement--namely, that packages
>other than Employee, including Office, have access to everything the
>Employee package wishes to put in its interface and to nothing else
>having to do with Employees (and similarly for Offices).  Thus, this
>is certainly an acceptable workaround for the problem.  But "clean"
>and "elegant"?  Maybe I'm being too much of a purist, but I have
>trouble characterizing something that requires adding this much code
>that has no meaning to someone reading the program, as elegant.  It
>seems more like a flaw in 9X that things have to be done this way.
>And based on my experience writing large Ada 83 programs, my gut
>instinct is that this is the sort of flaw that will be cursed by many
>9X users down the line.  I also realize that if we tried to make Ada
>9X absolutely perfect, it wouldn't be Ada 9X any more but something
>like Ada 23.  :-)

It is my understanding that a very early decision in the ada9X revision
process was to only add sufficiant new features to Ada to allow development
of OOP system using a building block approach.  In other words there should
be no "One True Way" to OOP in Ada9x.  Some of the early ideas proposed
for adding OOP to Ada9x would have forced a "One True Way" on the language
(E.G., adding package types).  Because Ada9x was designed using this
building block approach, some things might not end up looking as "Elegant"
of "Clean" as in other languages that do have a "One True Way", but the added
flexability should make designing OO system that use only as much of the OO
stuff as needed very simple compared to "One True Way" system that require
you to used everything whether you want it or not.  I personally thing
that the Ada9x design team has done an excellent job of sticking to the 
building block approach and have avoided a "One True Way" while providing
all the features needed to design OOP systems.

--
Mark Biggar
mab@wdl.loral.com