Design of the Ada95 object system

Design of the Ada95 object system

[Oliver.Kellogg]

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

Re: Design of the Ada95 object system

[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

Re: Design of the Ada95 object system

[Mats Weber]

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.

Re: Design of the Ada95 object system

[Mats Weber]

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.