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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,900edaa189af2033 X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Ada95 OOP Questions Date: 1996/08/21 Message-ID: #1/1 X-Deja-AN: 175705951 sender: news@organon.com (news) references: <4tf3l4$4hu@masala.cc.uh.edu> organization: Organon Motives, Inc. newsgroups: comp.lang.ada Date: 1996-08-21T00:00:00+00:00 List-Id: In article ecn@explorer2.clark.net (Eric C. Newton) writes: > My problem is that I like having *BOTH* a person package *AND* a > person class encapsulation mechanism. I can live with just one or the > other, but I like both. What does this give you? Certainly you can nest a person "class" package inside of a personS package. > The point of the (deleted) example was to show that a package is just > a namespace, and that multiple classes can live in that namespace, and > that the features of the class do not need to be visibly associated > with the dispatch object. Yes. And I "shrug" to that. Same sort of situation for Dylan or CLOS. Of course, that doesn't make it "good" by definition or something. Just that this is a specific design choice balancing various requirements, reasons, etc. > *I* know I can create little packages for each class. *I* know that > they are equivalent. I think there is a case to be made that the Ada > approach can be beneficial in some cases (such as in tightly coupled > classes such as Matrix and Vector). BUT, I think I would miss the ^^^^^ > textual grouping and extra encapsulation level Maybe. But I see the operative word here as "think". What's really at issue is "this is what I am used to". Which is a definite point, but can also close off potentially "better" alternatives. > I was just pointing out that Objects need not be encapsulated with > respect to each other and that dispatching is not obvious at the call > site. Actually, dispatching is _more_ obvious at the call site than in something like Eiffel or C++. That's because dispatching is a local thing - _indicated_ at the specific invocation. In C++ or Eiffel you indicate this dispatching (virtual in C++) or non dispatching (frozen in Eiffel [this is not quite the same, but prevents dispatch]) behavior back in the class definition. Also, once it's made it is pretty much fixed (you have to go back and hack the class to change it). In Ada you pick what you want at the particular call site and indicate it. In general this is pretty explicit: A : T; Op(T'Class(A)); -- Dispatch Op(A); -- No dispatch or A : T'Class; -- Typical of a class wide operation signature which -- will dispatch internally for specific behavior Op(A); -- dispatches... In any event for any call, you only need to look around _locally_ to see if the parameter to the Op is classwide - if so the Op dispatches. In the other two example cases, you have to go back to the class definition to be sure. > abstraction. I suppose that Object-Oriented programmers like myself > are simply looking for the comfortable encapsulated, abstract, > polymorphic entity they know and love in a single construct. This > discussion has helped me understand the Ada approach, and maybe it > will help me explain it to others. Sounds good to me! /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com