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,f4d5ed8a41b9fc83 X-Google-Attributes: gid103376,public From: mheaney@ni.net (Matthew Heaney) Subject: Re: Design of the Ada95 object system Date: 1997/11/25 Message-ID: #1/1 X-Deja-AN: 292551448 References: <880451634.2136@dejanews.com> Organization: Estormza Software Newsgroups: comp.lang.ada Date: 1997-11-25T00:00:00+00:00 List-Id: In article <880451634.2136@dejanews.com>, Oliver.Kellogg@vs.dasa.de wrote: >It would seem to me that the package constitutes the basic >encapsulation mechanism in Ada, and could be viewed as an >equivalent of the C++ class. I feel that using the record type as >the vehicle of object orientation constitutes a "double encap- >sulation" (package declaration scope plus tagged record type >declaration scope.) It's true that the package encapsulates, but an Ada package is *not* a C++ class. It's closer to a C++ namespace. A tagged type is equivalent to a class. This always trips up neophyte language designers. In Ada - by design - the module and the type are orthogonal language constructs. In C++ - by design - the module and type are the same. Differenct designers, different decisions. However, the Ada approach is smarter, because you still need a way to organize types, or otherwise there's a huge proliferation of type names in global namespace. Precisely the reason Stroustrup added a namespace. But Ada already has it: the package. Actually, Ada is better still, because you can organize namespaces in a hierarchy. >What I have in mind is something like a "tagged package". >A tagged package would not in itself constitute an instance >(as non-generic packages do), but rather a type declaration. That's not Ada. There was a preprocessor version of Ada 83, called DRAGOON, that did that. But believe me, you don't want the package to be a type. A package is not a type, it is a namespace. >It is of course a matter of taste, but I prefer the notation >"Object.Method" for a method invocation (as in C++ et al.) >rather than "Method(Object)". This exactly captures the >intended encapsulation -- everything inside the tagged >package declaration "belongs to" the object. Further, it >would be possible to have an implicit "This" or "Self" access >value to an instance of a tagged package like in other OOPLs. Both techniques capture the intended abstraction, they just do it differently. If you prefer one, it's only because that's how you've been doing it. Try Ada for a while - as is, without fighting the language - and you'll find the Ada approach is AOK. If you want to compare types, then compare an Ada tagged type to a C++ class. If you want to compare modules, then compare the Ada package to a C++ class. If you want to compare namespace, then compare package to namespace. >-- An example could look like this: >tagged package My_Object_Type is > > type Some_Type is new Integer range 0..99; > procedure Some_Proc (I : in out Some_Type); > XY : Some_Type := 50; > -- Type/subprogram/variable declarations as usual > >end My_Object_Type; This is totally not Ada. Just banish this from your mind. If you continue to think this way you will never be able to immerse yourself into the Ada way of thinking. In Ada, a module is not a type, and you're not going to be doing yourself any favors by wishing it were. It's like speaking French, if your native language is English. You don't speak French by translating English directly into French, then complaining how weird French is. You must speak *and* think in French - without translation from some other language. >If anyone can refer me to further reading explaining the choice of >object mechanism in Ada95, that'd be great. I've already consulted >the Ada95 Rationale and found some comparisons with other languages >at the end of chapter 4, but not a discussion of alternatives >considered for the Ada95 object system during language design. The decision to separate the concepts of module and type was made during Ada 83 design; try reading the Ada 83 Rationale. Ichbiah wisely recognized that you need some higher level organizing principle than the type, ie the package. What he didn't recognize was that you need some way to organize the packages too, and that's the innovative thing about Ada 95, the package hierarchy. Type extension was added during Ada 95 (tagged types), but the object model is the same as it was in Ada 83. -------------------------------------------------------------------- Matthew Heaney Software Development Consultant (818) 985-1271