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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,66253344eaef63db X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,66253344eaef63db X-Google-Attributes: gid1108a1,public X-Google-ArrivalTime: 1994-10-05 12:16:02 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!news.duke.edu!eff!blanket.mitre.org!linus.mitre.org!linus!mbunix!eachus From: eachus@spectre.mitre.org (Robert I. Eachus) Newsgroups: comp.lang.ada,comp.object Subject: Re: Mut. Recurs. in Ada9X w/o Breaking Encaps.? (LONG) Date: 5 Oct 94 11:42:39 Organization: The Mitre Corp., Bedford, MA. Message-ID: References: <1994Sep27.165203.9192@swlvx2.msd.ray.com> <36bt0c$17oo@watnews1.watson.ibm.com> <1994Sep29.103358@di.epfl.ch> <36eebb$jn5@disunms.epfl.ch> <1994Oct2.164105.13127@swlvx2.msd.ray.com> <1994Oct4.160056.4243@swlvx2.msd.ray.com> NNTP-Posting-Host: spectre.mitre.org In-reply-to: jgv@swl.msd.ray.com's message of Tue, 4 Oct 1994 16:00:56 GMT Xref: bga.com comp.lang.ada:6504 comp.object:7069 Date: 1994-10-05T11:42:39+00:00 List-Id: 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...