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

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <1994Oct1.014758.10687@swlvx2.msd.ray.com> jgv@swl.msd.ray.com (John Volan) writes:

  > ... Suppose, instead of just writing package
  > "Employees_And_Offices", we had to write package "Company".
  > Suppose we tried to support not only Employees and Offices, but
  > also other things in the problem domain of Company management.
  > Things like Memos and Meetings and Job_Descriptions and
  > Inventories and Stock and Benefits and so on and on and on ...

   Hmmm... I can have a model of a company MIS environment where there
is one package of high-level abstractions such as people, places, and
things.  I can also have lower-level abstractions, which can be a
hierarchy of child packages, since I want to have this as a sub
system.  Seems like a reasonable approach, we just have to rename some
of the types in the examples:

    type People is abstract tagged private;
    type People_Pointer is access People'Class;
    ...etc.

    Now everything at the top level seems reasonable, and the lower
down decisions, such as whether consultants can be assigned offices,
is implementable at the appropriate level.  Adding attributes to the
top level abstraction of people will require modifications to the root
package, for example adding a fax number field, or a teleport address.

    I assume that such modifications occur at a relatively slow pace,
but notice that recently we have had at least TWO additions to
business cards--fax number and e-mail address.  The previous sucn
change was the addition of telephone numbers (or perhaps area codes
for telephone numbers).  But that started happening about a century
ago.  (Area codes started appearing in the late fifties.)  The next
addition will probably be photographs--the MITRE on-line directory has
them now.

  > On the other hand, if we can manage to maintain 1 Package = 1
  > Class even despite mutual recursion, then we at least have some
  > hope of managing a large, complex problem -- one class at a time.
  > Isn't that what object-orientation is all about?

    Here I have to disagree, but it may be an issue of terminology.
In Smalltalk there is ONE superclass.  Do you hear complaints about
Smalltalk which state that this prevents encapsulation?  No.

    As I see it you are really arguing that superclasses shouldn't
have to "know" about subclass specific interfaces and details.  Stated
that way, I don't have a problem with your assertion, or with Ada 9X.

    However, identifying the appropriate level in the tree for a
specific interface is always going to be a hard problem.  And we are
going to spend a lot of time fixing wrong guesses.  That is a part of
the design (and programming) process, and probably can never be
eliminated entirely.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...