Re: AQ&S Guidance on pragma Elaborate_Body

["John G. Volan" <johnvolan@sprintmail.com>]

Sorry to follow-up the same post twice, but:
Matthew Heaney wrote:
> 
> In article <33660F4B.1B45@sprintmail.com>, johnvolan@sprintmail.com wrote:
...
> >Of course, if it's just "a pair of abstract data types that are
> >intimately related", and that's all there is to it, then the cost of
> >abstraction-loss is relatively small, so co-encapsulation may be a
> >reasonable option.
> 
> That's all I was saying: a pair of ADTs that are intimately related.

But that's a straw man -- yes, sometimes there are isolated pairs of
abstractions that are so tightly coupled to each other that they really
do belong in the same package. I readily concede that possibility.  But
that's not what I was talking about when I said: 

> But what if that's not all there is to it?  Then the transitivity
> problem rears its ugly head: If class A is "intimately related" to class
> B, and class B is "intimately related" to class C, you may be forced to
> co-encapsulate A, B, and C, despite the fact that you did not envision
> any "intimate relationship" between A and C in your original software
> design.

I was actually talking about situations where the coupling between
classes was relatively loose: Let's just consider what happens in
general when classes collaborate with each other through basic
client-supplier relationships.  Each class, in general, can be both a
supplier of services to several other classes, and a client of the
services of several other classes.  As a supplier, each class should
provide an abstract interface for its clients; as a client, each class
should be happy to interact with its suppliers through their abstract
interfaces.  No client class should ever need to know anything about the
internal details of its suppliers.  That's what abstraction and
encapsulation are all about.

Now, in many cases, a class's set of clients and set of suppliers will
be disjoint sets.  But sometimes these two sets might just happen to
overlap, and in the intersection a class may be treating another class
both as a supplier and a client. In Ada95, this leads to a situation
where two package bodies "with" each other's specs.  Matthew, you argued
that this was a warning sign that the classes in the two packages were
"intimately related", constituting a single abstraction that ought to be
co-encapsulated into a single package.  Many have made this contention,
especially in the early days of Ada83.  But why should we make a
distinction between one kind of client (or supplier) and another?  

As I've already pointed out, co-encapsulating such pairs of classes
unnecessarily breaks down the abstraction barrier between them, and this
effect can be transitively infective.  There are, in fact, viable
software designs where every class's client-set and supplier-set happens
to be _identical_ -- i.e., _every_ association between classes gets
implemented as a mutual, bidirectional client-supplier relationship.  If
we go with what you advocate, then such designs are doomed to be
implemented as single, monolithic packages.  If so, then what was the
point of inventing packages in the first place?

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------