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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC 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: ecn@explorer2.clark.net (Eric C. Newton) Subject: Re: Ada95 OOP Questions Date: 1996/08/14 Message-ID: X-Deja-AN: 174171369 references: <4tf3l4$4hu@masala.cc.uh.edu> content-type: TEXT/PLAIN; charset=ISO-8859-1 organization: Newton Consulting, Inc. mime-version: 1.0 reply-to: ecn@clark.net newsgroups: comp.lang.ada Date: 1996-08-14T00:00:00+00:00 List-Id: In article jsa@alexandria (Jon S Anthony) writes: Basically, because no one knew what the "right" dispatch policy should be in such cases and no one had any intention of putting in something like the MOP. So, it didn't happen. Yes, multiple argument dispatching is a difficult thing to reason about, and I'm just a lowly mortal. Ada's syntax only suggested such a thing to me. I figured someone else worried about making it work safely. I see no reason why _passive_ entities (the so called objects for either of the above) should look like they are acting or being commanded to act. If you want that then use an activity which in Ada would be modeled by a task: Yes, a task is a good model for an active thing. Perhaps I should have said "This is a Person. It manages person-state, and satisfies person-services, as listed in the encapsulated person class." But, you would say: "This is a person. It represents the private state used by the services encapsulated in the person package." 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. > package Matrixes is Shrug. And? 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. Matrixes encapsulates Matrix *and* Vector types. I can list the Matrix and Vector operations willy-nilly within this namespace. In C++/Modula-3 I must list the operations on the private state of Matrix within the Matrix class. I must list the operations on the private state of Vector within the Vector class. There is visible association of dispatch methods and type. *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. I'm just trying to cross the bridge between traditional object languages and the approach taken by Ada. They share almost no vocabulary and use different words for similar things, and they look completely different. Of course, smalltalk lets you put a method anywhere, at any time, right? You rely on the browser to provide the "grouping of methods." So there's a tradition of other mechanisms, too. > I keep trying to see packages like I see objects and it just doesn't > get any easier. That's because they aren't objects/classes. They are orthogonal constructs. Classes are classes (T'Class, e.g.), objects are objects ( Obj : T, e.g.) Yes, they are orthogonal, but you *almost* always want a class encapsulated. So in other OO languages, I get some encapsulation with a class, in Ada I have to create a new package. On the other hand, there is no need for the C++ "friend". > Namespaces are good. Objects are good. Yes, Ada 95 > has both, but it is pretty good at hiding the objects. Huh? An object is quite explicit and obvious: X : T; -- X is an object for any type T. Pretty clear and obvious. 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. The use of "tagged" is indeed controversial... It encourages me to think of Ada's mechanisms as a way add in dispatching, rather than a means for organizing my runtime architecture. Dispatching/polymorphism is a powerful tool for 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. -Eric -- Eric C. Newton Software Reuser. Newton Consulting Look at all the code I didn't write today! ecn@clark.net http://www.clark.net/pub/ecn/home.html