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

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

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

  > This approach is nice, as long as we are willing to give up having
  > these operations be primitives for their respective tagged types.
  > I guess the only way I'd expand on this would be to make these into
  > child packages rather than just child functions.

  Yep, it may be a trade off, or it may be just what you wanted.  It
depends on whether the association is an integeral part of the
abstraction.  If it is, I'd use one of the other techniques.  But if
it is peripheral to the definiton of the class this is probably the
way to go.

  > Also, it looks like this scheme gives up on the possibility of
  > incorporating the pointers directly into the tagged record types
  > themselves, since they would still need to be declared in the private
  > parts of the root packages somehow.

    I'll answer this here, instead of with the "abstraction breaking"
comment.  If you implement the parent type with a explicit pointer to
an extension area, then the definition of that area can be deferred to
the package body.  Works fine, and you can even go through the
gymnastics of making the extensions a linked list of arbitrary fields
by having a private child export a generic which can be instantiated
for each different type of extension.

    The "problem" is that this gives a nice clean external interface
while having all sorts of complex structures "under the covers."
That's why the abstraction breaking comment.

  > I guess the real philosophical issue that everything is hinging on
  > here is: "Is a binary association *part* of the abstraction of
  > each of the classes, or is it a *separate* abstraction of its
  > own?"

   Change one word and you've got it exactly right: "Is THIS binary
association..."  You will almost certainly come up with different
answers in different cases, and Ada 9X supports--as we have just
seen--several abstractions, each appropriate for a different reality.

  > But a corollary to this issue is the question: "Do association
  > operations *need* to be primitives of each of the associated classes?"
  > I'm beginning to think not, but I'm not sure I have a good handle on
  > this question yet.  Any thoughts?

   Yep!  Some do, some should not be.  See above.

  > I'm not sure what you mean by "abstraction breaking".  Is there
  > some trick we could use to get those pointers into the tagged
  > records after all?  Perhaps "opaque" forms of the pointers that
  > somehow get converted to "transparent" forms later?

  Several solutions.  You hint at one which works.  You can have a
abstract class, and a type which is a pointer to all objects decended
from it:
 
  package Pointers is
   type Everything is abstract tagged null record;
   type Pointer is access all Everything'Class;
   ...
  end Pointers;

    Now you make Employees and Offices children (or grandchildren) of
everything, and on as before.  This looks like combining Office_Parent
and Employee_Parent from earlier examples, and in a sense it is.
However, replace Everything with Controlled, and it makes a lot more
sense. You lose some strong type legality checking, but good compilers
should be able to warn you of incorrect downcasts before run-time.
(Interesting side note here.  A good compiler integrated with an
annotation language would allow better compile time warnings, I don't
know that pragma ASSERT is sufficient.)

 > I don't think there's any problem here. It seems to me the most
 > reasonable interpretation of a Rumbaugh-style Object Model would not
 > allow subclasses to alter the nature of an association (at least, in
 > structural terms) which was established by a superclass.  If we were
 > tempted to do so, then I think we'd have to question the quality of
 > our analysis model (e.g., "does this association really apply to this
 > whole superclass?").

   Agreed, I was just trying to point out cases where this approach
would not be the right choice.

  > >it would be to change 3.2.3(6) to make
  > >child units eligible as primitive operations, probably under the
  > >influence of a pragma.   I certainly don't recommend such a change to
  > >the standard--it would open up all sorts of holes--but that should
  > >prevent someone from experimenting with such a pragma.

 > Certainly would be an interesting experiment, but dangerous. (Wear
 > protective gear. ;-) The difficulty I see is that the primitive
 > interface of a tagged type (embodied in its tag, perhaps implemented
 > as a method jump table) would be a fluid thing, dependant on how many
 > child units were actually compiled and "withed" within a program.  It
 > seems that a compiler alone would not be able to resolve this, and
 > that it would have to be a function of a linker.

   In general, the linker is going to have to do part of the building
of jump tables now, so that is not a drawback.  The problems would
occur in the implementation of compile time overload resolution,
especially for non-tagged types. (Ouch!)  An experimental compiler
could make all such bindings non-static and resolved through jump
tables, but a usable compiler that only used jump tables where
necessary would be an interesting research project.  (Compiling a
child unit into the library might have to result in recompiling units
which depend on the parent, even if they are unaware of the child.
The old "legal with respect to units they do not depend on (see
AI-256)" Pandorra's box.)

    This discussion has been very interesting. I'm beginning to think
that we are starting to understand this new language.  From what I
have seen it is going to be a very nice place to live.


--

					Robert I. Eachus

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