From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,baa6871d466e5af9 X-Google-Attributes: gid103376,public From: "John G. Volan" Subject: Re: AQ&S Guidance on pragma Elaborate_Body Date: 1997/05/02 Message-ID: <3369A35F.5691@sprintmail.com>#1/1 X-Deja-AN: 238844383 References: <528878564wnr@diphi.demon.co.uk> <5jabeq$3ltk@info4.rus.uni-stuttgart.de> <5jfukp$lda@top.mitre.org> <33660F4B.1B45@sprintmail.com> Organization: Sprint Internet Passport Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.ada Date: 1997-05-02T00:00:00+00:00 List-Id: 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? :-) "); ------------------------------------------------------------------------