Re: Design of the Ada95 object system

[mheaney@ni.net (Matthew Heaney)]

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