Re: AQ&S Guidance on pragma Elaborate_Body

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

Matthew Heaney wrote:

> I'm talking about just a pair of abstract data types that are intimately
> related.  But I sense that you and the other posters are talking about
> large packages (say, a subprogram library such as binding).

"Co-encapsulation," as I like to call it, has a cost: Loss of
abstraction. Because both types have visibility to each other's private
features, there is no way to enforce each to adhere to the discipline of
only calling the other's public interface. This affects
understandability: Readers must understand what both types are doing,
internally, before they can be sure they know what either type is doing.

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.

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.

What if you've used an object-oriented analysis and design method, such
as OMT or UML, to develop a model of your application domain comprised
of a lot of classes linked together by a lot of binary associations? 
*Any* binary association might be construed as an "intimate
relationship" between the two clases involved.  But each class may be
involved in several associations.  And if your model is complete, I
believe it should form a single contiguous graph of classes linked by
associations, with no isolated islands.

Under these circumstances, if you allow the transitivity effect to
proceed unchecked, it can spread like a virus to infect your entire
application. Robert Dewar hits on this problem:

Robert Dewar wrote:
> 
> ... -- it is really a natural
> consequence of any domain in which recursion is an important idiom.
>
> For example, if we have a compiler with separate units to handle if statements
> and loop statements, it is natural for if's to have loops and loops to have
> if's. Surely you don't think this means that we have to put loops and if's
> in the same unit -- because if you do you are syaing the whole compiler must
> be one unit!

Here, I take "recursion" to mean "recursive data structures," where an
object of one type may contain references to objects of another type,
and vice versa.

I would go one step further: The transitivity problem doesn't just
affect applications that involve this kind of recursion.  *Any* binary
association, conceived of during object-oriented analysis, is
potentially vulnerable when you get to the design stage, and have to
decide whether the association needs to be traversible in one direction,
or the other, or both.  A mutually-recursive data structure is just one
way of implementing bidirectional traversals, but it's not the only way.

It was this transitivity problem that prompted me to kick off that long
thread a couple of years ago, and it was the seriousness of this
problem, as I saw it, that prompted me to pursue that thread for so
long.

------------------------------------------------------------------------
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? :-) ");
------------------------------------------------------------------------