Re: Ada Objects Help!

[Stephane.Barbey@di.epfl.ch (Stephane Barbey)]

From barbey Mon Jan 23 11:51:37 1995
Date: Mon, 23 Jan 95 11:51:34 +0100
From: barbey (Stephane Barbey)
To: hathawa2@marshall.edu (Mark S. Hathaway)
Cc: Stephane.Barbey
Subject: Re: Ada Objects  Help!

In article <1995Jan20.134150@hobbit>, you write:
: > In article <1995Jan16.132400@lglsun.epfl.ch>,
: > nebbe@lglsun.epfl.ch (Robb Nebbe) writes:
: 
: >> In article <3f9g1u$j4m@nps.navy.mil>, swdecato@nps.navy.mil writes:
: 
: >> I wan't to duplicate the following C++ code in Ada.

... but I do not want to duplicate it in this post.


: It's not obvious if 'myclass(int)' is creating a list of objects of type
: myclass or if it's assigning 10 --> dataelement.  It's not very eloquent.

What is obvious is that myclass(int) is a constructor that takes an
integer as a parameter.

: Then the Ada example changes 'myclass(int)' to 'Create(X : Integer) return T'
: with the added complexity of defining T. 

So it is a (member) function that returns an object of type T and takes
an integer as a parameter... It seems to me to be an (almost)
acceptable translation of the C++'s class spec.

: It looks wrong or overly complex.

It isn't wrong. I do not think it is complex either, because the
translation from C++ to Ada 95 is straightforward in this example.

I do not see the complexity in having to define T either. A C++ class
is simultaneously a package and a type, thus the Ada 9X defines a
package and a type. 

I'guess you'll say that it is a lack of unification (See Meyer's seven
sins of OOP), but then, in C++, you find the (strange to me) concept of
having the files (i.e. an OS concept) as a means of modularity, thus
having visibility rules applied to entities defined in the file vs.
other files and visibility rules applied to entities defined in classes
vs. the rest of the world, but the different kind of friends hat have
access to what even your descendants can't see.

Ada has no "bastard unification" between type and class, but unifies
what need to be unified, i.e. packages are the construct to handle
modularity & encapsulation. 

[ObAdvertisement: take a look at my paper in the proceedings of TRI-Ada
94, which handle some of these issues.]


: 
: Here's my idea of how it should look.
: 

[An idea of how it should look in Eiffel++]

: 
: Isn't this closer to what the C++ example is "saying"?
: 

No.

For instance because it is not the same state machine. In your
example, it is possible to call Display between New and Assign, thus it
is possible to try to call Display on an "unitialized" object, which is
not allowed by the C++ spec. Not familiar with oo software testing, are
you?

Note that this is also possible in Rob's spec. (That's why I said that
it was "almost" acceptable.)

My translation would be (by diff'ing Rob's spec):

> package P is  -- Just the specification
>    type T is tagged private;

     type T (<>) is tagged private;
     -- so that no object of T can be created without
     -- initializing it first (here by calling Create).  

>    function Create( X : Integer ) return T;

     function Create (X: Integer) return T'Class;
     -- because in C++, constructor operations are not inherited.
     -- [See my TRI-Ada paper on that point too.] 
      
>    procedure Display( X : T );
> private
>    type T is tagged
>       record
>          Data_Element : Integer;
>       end record;
> end My_Package;

  end P;
  -- to please the compiler.
  

-Stephane

--
Stephane Barbey				"It's not easy getting real wings"	
INJ-335, barbey@di.epfl.ch