* Design of the Ada95 object system @ 1997-11-25 0:00 Oliver.Kellogg 1997-11-25 0:00 ` Matthew Heaney 1997-11-28 0:00 ` Mats Weber 0 siblings, 2 replies; 4+ messages in thread From: Oliver.Kellogg @ 1997-11-25 0:00 UTC (permalink / raw) Having written my first few programs in C++, following question comes to me concerning the object system of Ada95. During the language design, was it ever considered to use the *package* (instead of, as it were, the record type) as the basic object mechanism? 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.) 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. 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. -- 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; -- Here's an example of using the above package: with My_Object_Type; with Text_IO; procedure Main_Program is package My_Object is new My_Object_Type; -- instantiation -- Perhaps the syntax for instantiation should rather be: -- My_Object : My_Object_Type; ? begin My_Object.Some_Proc (My_Object.XY); Text_IO.Put_Line (My_Object.Some_Type'image (My_Object.XY)); end Main_Program; -- Here's an example of extending the tagged package: with My_Object_Type; tagged package My_Extension is new My_Object_Type with Z : Some_Type := 51; procedure Some_Proc (I : in out Some_Type); -- overrides the declaration in My_Object_Type. end My_Extension; I'll be quick to admit that this is not yet well thought out. For example, one criticism that immediately comes to mind is the impossibility to declare an access-to-tagged-package type outside of any enclosing scope. (OTOH, perhaps there's no need for such a type -- need to think about that.) 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. --Oliver Oliver.Kellogg@vs.dasa.de -- These opinions are MINE and do not represent those of DASA -- -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Design of the Ada95 object system 1997-11-25 0:00 Design of the Ada95 object system Oliver.Kellogg @ 1997-11-25 0:00 ` Matthew Heaney 1997-11-28 0:00 ` Mats Weber 1997-11-28 0:00 ` Mats Weber 1 sibling, 1 reply; 4+ messages in thread From: Matthew Heaney @ 1997-11-25 0:00 UTC (permalink / raw) 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 <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Design of the Ada95 object system 1997-11-25 0:00 ` Matthew Heaney @ 1997-11-28 0:00 ` Mats Weber 0 siblings, 0 replies; 4+ messages in thread From: Mats Weber @ 1997-11-28 0:00 UTC (permalink / raw) Matthew Heaney wrote: > 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. Smarter ? Well I think that the way operations and types are linked together (i.e. when they appear in the same package spec) is not that smart. There are many problems with that approach, like the freezing rules, unwanted links (e.g. derive Text_IO.Count and you get new versions of New_Line, etc.) and links that are just not there (e.g. an opeation expressed as a generic is never derived/inherited). > >-- An example could look like this: > >tagged package My_Object_Type is > > > > type Some_Type is new Integer range 0..99; You probably don't want to declare types inside package types. > > 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. Have you ever used task types ? They make you think just that way. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Design of the Ada95 object system 1997-11-25 0:00 Design of the Ada95 object system Oliver.Kellogg 1997-11-25 0:00 ` Matthew Heaney @ 1997-11-28 0:00 ` Mats Weber 1 sibling, 0 replies; 4+ messages in thread From: Mats Weber @ 1997-11-28 0:00 UTC (permalink / raw) To: Oliver.Kellogg Oliver.Kellogg@vs.dasa.de wrote: I agree with you. I would also have preferred package types for the Ada 95 OO stuff. But there has already been much discussion on that subject in c.l.a. > 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. I did my PhD thesis on exactly that subject. It's on the Web at <http://lglwww.epfl.ch/Team/MW/Ada-Extensions/Ada-Extensions.html>. You can also retrieve past discussions on the subject with dejanews. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1997-11-28 0:00 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-11-25 0:00 Design of the Ada95 object system Oliver.Kellogg 1997-11-25 0:00 ` Matthew Heaney 1997-11-28 0:00 ` Mats Weber 1997-11-28 0:00 ` Mats Weber
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox