Ada OO

Ada OO

[Graham Hughes]

-----BEGIN PGP SIGNED MESSAGE-----

I apologize if this has been glossed over before, but I didn't notice
anything immediately through the back articles.

The tutorials at http://www.adahome.org/ seem to gloss over the way Ada
OO is handled; possibly this is because they believe it to be so simple
that their explanation suffices.  However, I'm coming from C++, where OO
is quite complicated, and I'm not sure I've quite got a handle on it
yet.

- From what I've seen, Ada OO is very similar to CLOS; both use the

    Object_Method(Object, Args);

syntax instead of the C++-style

    Object.Object_Method(Args);

where Object is a tagged record.

Given this, how are C++-style virtual methods defined?  The stuff I've
looked at implied that all subprograms defined in the package spec are
virtual, and pure virtual methods are achieved by (appending?
prepending?) abstract to the definition.

With CLOS, all defmethod (or is it defgeneric? been a while) methods are
effectively virtual, and pure virtual methods are just a defgeneric (?)
with no body definitions.  Is this the way Ada OO works?

Finally, re: the abstract; is it needed in the package body, or can it
be ommitted?

Thanks for any help.
- -- 
    Graham Hughes (graham.hughes@resnet.ucsb.edu)
alt.PGPlike-key."graham@A-abe.resnet.ucsb.edu".finger.look.examine
alt.homelike-page."http://A-abe.resnet.ucsb.edu/~graham/".search.browse.view
alt.silliness."http://www.astro.su.se/~robert/aanvvv.html".look.go.laugh

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMpjr6iqNPSINiVE5AQFw3AP/UMeHylSkz0Y++9uvJsbPSbTwmQH4Y3vF
eN5AiLyTLtXFyk4TQqs7cVjhhd8yDfv1mhtU5eWA/NIAcHEhbcdggz4qr8/6j1zR
ZcAE65nRY9s6dbsPXRYzZJiZYkbEygS3SaHuZxm1NAfrOoSE1zsgTlf6cAsmsfAC
agpg1XlnA58=
=d/vL
-----END PGP SIGNATURE-----

Re: Ada OO

[Robert A Duff]

In article <57aq7s$30j@yuggoth.ucsb.edu>,
Graham Hughes  <graham.hughes@resnet.ucsb.edu> wrote:
>- From what I've seen, Ada OO is very similar to CLOS; 

The syntax is similar, but other than that, they are not similar.
CLOS is vastly more powerful, and more complicated, than Ada
(or any other OO language I've ever used).

In particular, CLOS has multi-methods, whereas Ada does not.

>Given this, how are C++-style virtual methods defined?  The stuff I've
>looked at implied that all subprograms defined in the package spec are
>virtual, and pure virtual methods are achieved by (appending?
>prepending?) abstract to the definition.

That's right -- if one or more parameters are of type T, and T is
tagged, and the procedure is in the same package as T, then it's virtual
(which Ada calls "dispatching").  And right, pure virtual is pretty much
the same thing as abstract.  Dispatching-on-function-result is something
C++ doesn't have.  Also, Ada has class-wide parameters -- a procedure
with class-wide parameters is not dispatching (unless some other
parameter makes it so).

>With CLOS, all defmethod (or is it defgeneric? been a while) methods are
                                                ^^^^^^^^^^^^
Yeah, me too.  I haven't used it since it was called "Flavors".
>effectively virtual, and pure virtual methods are just a defgeneric (?)
>with no body definitions.  Is this the way Ada OO works?

Well, sort of.  But in CLOS the methods are scattered all over,
whereever the programmer chooses.  In Ada, they're collected together in
a single package.

>Finally, re: the abstract; is it needed in the package body, or can it
>be ommitted?

Umm.  Not sure what you mean.  Can you give an example?  Usually,
"abstract" is placed on the type, and on some or all of its "methods",
and the type is *usually* in a package spec, not a package body.  And if
the method is abstract, it has no body in the package body.

- Bob

Re: Ada OO

[Graham Hughes]

-----BEGIN PGP SIGNED MESSAGE-----

bobduff@world.std.com (Robert A Duff) writes:

>The syntax is similar, but other than that, they are not similar.
>CLOS is vastly more powerful, and more complicated, than Ada
>(or any other OO language I've ever used).

I can definitely agree with that; never seen :around, :before, or :after
anywhere else.  Even Smalltalk doesn't allow the extreme hair you can
see with metaclasses.

>                        Dispatching-on-function-result is something
>C++ doesn't have.  Also, Ada has class-wide parameters -- a procedure
>with class-wide parameters is not dispatching (unless some other
>parameter makes it so).

This is probably because I learned OO on my own, but what exactly is
`dispatching-on-function-result', and class-wide parameters?  Does the
last refer to the way you specify parameters when instantiating a
generic?

>Well, sort of.  But in CLOS the methods are scattered all over,
>whereever the programmer chooses.  In Ada, they're collected together in
>a single package.

Which is quite handy some times, I've noticed.

>>Finally, re: the abstract; is it needed in the package body, or can it
>>be ommitted?

>Umm.  Not sure what you mean.  Can you give an example?

Basically, I was kind of confused whether you needed to mention an
abstract method/subprogram in the package body, or whether you could
just assume everybody knows what you mean.  Fortunately, the latter is
true :).
- -- 
    Graham Hughes (graham.hughes@resnet.ucsb.edu)
alt.PGPlike-key."graham@A-abe.resnet.ucsb.edu".finger.look.examine
alt.homelike-page."http://A-abe.resnet.ucsb.edu/~graham/".search.browse.view
alt.silliness."http://www.astro.su.se/~robert/aanvvv.html".look.go.laugh

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMpnr2CqNPSINiVE5AQFnhwP/VMprD5ZNkPNU3Yq4N+mlx/dLBleLvSPd
XJ5qxHXC2+TdVu+EU2MDGoC8CjuTp6bjhDjDV+AmSNrZ4qqf56aVug32WQ/B//2V
xJX3wvNSaDmovKlDhWasIbu3PII6bx8S6IeykCdwB7O6CQhfqPdtdSIDmAJGnDSR
bZTnA98gmG4=
=VStO
-----END PGP SIGNATURE-----

Ada OO

[Rick Duley]

Hi all

I believe that I am the last surviving academic Ada programmer in Perth, 
Western Australia and I am in need of some help.  I am having problems 
coming to terms with the rationale behind Object Oriented programming in Ada 
and there is no-one I know in Perth to talk to.  I'm hoping you folk won't 
mind giving me a hand.

Perhaps I had better start by explaining my (mis-) understanding of the 
general principle of inheritance.

Suppose I have defined an object Pen_Class to have the form:

+-------------------------------------------+
| Pen                                       |
+-------------------------------------------+
| X     : Integer;                          |
| Y     : Integer;                          |
| Color : Color_Type;                       |
+-------------------------------------------+
| procedure Move_To(This : in out Pen;      |
|                   X    : in     Natural;  |
|                   Y    : in     Natural); |
| -- move the pen to the specified location |
| --  without drawing                       |
|                                           |
| procedure Draw_To(This : in out Pen;      |
|                   X    : in     Natural;  |
|                   Y    : in     Natural); |
| -- draw a line from the current location  |
| --  to (X,Y) using the pen's              |
| --  current color.  the pen's location    |
| --  moves to (X,Y)                        |
|                                           |
| function New_Pen(X     : Natural;         |
|                  Y     : Natural;         |
|                  Color : Color_Type)      |
| return Pen_Access;                        |
| -- returns access to an initialised Pen   |
+-------------------------------------------+

This object should be initialised by New_Pen and all the functionality it 
should need should be supplied by the other two methods.  Of course, if you 
want to change Pen Colour in midstream you would have to provide the 
functionality to do so but let's keep this simple so I can get a handle on 
it ;)

Extension of this class to Thick_Pen_Class should, according to me, result 
in a class having the form:

+-------------------------------------------+
| Thick_Pen                                 |
+-------------------------------------------+
| X         : Integer;                      |
| Y         : Integer;                      |
| Color     : Color_Type;                   |
| Thickness : Positive;                     |
+-------------------------------------------+
| --=== inherited from Pen_Class ===--      |
| procedure Move_To(This : in out Pen;      |
|                   X    : in     Natural;  |
|                   Y    : in     Natural); |
| -- move the pen to the specified location |
| --  without drawing                       |
|                                           |
| procedure Draw_To(This : in out Pen;      |
|                   X    : in     Natural;  |
|                   Y    : in     Natural); |
| -- draw a line from the current location  |
| --  to (X,Y) using the pen's              |
| --  current color.  the pen's location    |
| --  moves to (X,Y)                        |
|                                           |
| function New_Pen(X     : Natural;         |
|                  Y     : Natural;         |
|                  Color : Color_Type)      |
| return Pen_Access;                        |
| -- returns access to an initialised Pen   |
|                                           |
| --=== new in Thick_Pen_Class ===--        |
| procedure Move_To(This : in out Thick_Pen;|
|                   X    : in     Natural;  |
|                   Y    : in     Natural); |
| -- move the pen to the specified location |
| --  without drawing                       |
|                                           |
| procedure Draw_To(This : in out Thick_Pen;|
|                   X    : in Natural;      |
|                   Y    : in Natural);     |
| -- draw a line from the current location  |
| --  to (X,Y) using the pen's              |
| -- current color.  the pen's location     |
| --  moves to (X,Y).  The                  |
| -- vertical thickness of the pen is given |
| --  by Thickness.                         |
|                                           |
| function New_Thick_Pen                    |
|    (X         : Natural;                  |
|     Y         : Natural;                  |
|     Color     : Color_Type;               |
|     Thickness : in Positive)              |
| return Thick_Pen_Access;                  |
| -- returns access to initialised Thick_Pen|
|-------------------------------------------+

I would expect all the class attributes, the data variables, to be accessed 
by the methods of the derived class with the overloading providing the 
polymorphism.  My problems start when this doesn't happen.

1.   All the texts I can find which deal in any degree at all with OO in Ada 
teach that the tagged record in an object declaration should be 'private'.  
When you follow this line, a derived class does not have direct access to 
the object attributes of the base class, i.e. _there_is_no_inheritace_.

2.   To provide the derived class with access to the object attributes of 
the base class I have to create user-defined methods in the base class.  
This has two effects:
     a) the object attributes of the base class are now effectively public, 
i.e. accessible (through the user-defined methods) to any client module 
through 'with' and 'use' -  which effectively negates the act of making them 
private in the first place;
     b) having to provide accessibility in this manner emphasises the fact 
that inheritance did not occur.

3.   If the tagged record in the base class is left public and the derived 
class is in a child package of the package defining the base class, then the 
base class attributes are accessible to the derived class.  So far so good 
:)  However, if in a program 'use'ing the child package of 'Thick_Pen' (and 
not mentioning the base package of 'Pen') I make a call to the routine 
'Draw' with an actual parameter of the type 'Pen' I get a compiler error 
message to the effect that 'Draw' is not visible.  In other words, Thick_Pen 
has not inherited the operation Draw for 'Pen'  Again, 
_there_is_no_inheritace_.

4.  Further along that line, Thick_Pen does not inherit the type Pen so I 
cannot declare a Pen (or Pen_Access) unless I 'with' and 'use' the package 
in which Pen is declared.  This means that making the package in which 
Thick_Pen is declared a child of the package in which Pen is declared 
totally useless.  _There_is_no_inheritance_!

I have to say that this is the first time in pretty near a decade I have 
been writing in and teaching with Ada that Ada hasn't come up with the 
goods.  Do I labour under some serious misunderstanding, do I have something 
terribly wrong?

5.   One final thing (for this time anyway ;), why is it that that Ada does 
not use the intuitive 'object.method' syntax for making calls to and object. 
   This would mean that (in the case described in section 3) the call would 
read

	Pen.Draw(To_X => n, To_Y => n);

and with inheritance this would be accessible through the child package 
declaring Thick_Pen.  While I'm okay with using the existing syntax, I feel 
the 'object.method' syntax is more intuitive and in line with OO thinking.  
If there are people working on Ada0x then maybe we shoo\uld be putting this 
forward for consideration.


So, you see, I'm all at sea.  Can someone help me out?
Thanks



-------------------------------------------------
Rick Duley
23/209 Walcott St
North Perth, Western Australia 6006
mob: +61 040 910 6049
                                /-_|\
                               /     \
                         perth *_.-._/
                                    v
Experience is the worst of teachers
       It gives you the exam
                before it gives you the lecture


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Re: Ada OO

[John McCabe]

On Tue, 08 Oct 2002 02:17:07 +0000, "Rick Duley"
<rickduley@hotmail.com> wrote:

>1.   All the texts I can find which deal in any degree at all with OO in Ada 
>teach that the tagged record in an object declaration should be 'private'.  
>When you follow this line, a derived class does not have direct access to 
>the object attributes of the base class, i.e. _there_is_no_inheritace_.

If you make the tagged type declaration private and still want
inheritance your extensions of the tagged type must be created in
child packages of the original tagged type.

>2.   To provide the derived class with access to the object attributes of 
>the base class I have to create user-defined methods in the base class.  

You shouldn't have to do this if you leave the tagged type declaration
public, *or* create the tagged extension in a child package of the
package declaring the base class.

>3.   If the tagged record in the base class is left public and the derived 
>class is in a child package of the package defining the base class, then the 
>base class attributes are accessible to the derived class.  So far so good 

True, but the base class attributes will also be accessible to the
derived class if it is in a child package and the tagged type is
private. A child package always has visibility of its parents' private
parts (so to speak).

>:)  However, if in a program 'use'ing the child package of 'Thick_Pen' (and 
>not mentioning the base package of 'Pen') I make a call to the routine 
>'Draw' with an actual parameter of the type 'Pen' I get a compiler error 
>message to the effect that 'Draw' is not visible.  In other words, Thick_Pen 
>has not inherited the operation Draw for 'Pen'  Again, 
>_there_is_no_inheritace_.

There is an easy answer to this that I can't remember at the moment.
It's probably to do with using 'Class somewhere, but it may be that
you have an incorrect declaration somewhere that isn't actually a
creating a dispatching operation.

>4.  Further along that line, Thick_Pen does not inherit the type Pen so I 
>cannot declare a Pen (or Pen_Access) unless I 'with' and 'use' the package 
>in which Pen is declared.  This means that making the package in which 
>Thick_Pen is declared a child of the package in which Pen is declared 
>totally useless.  _There_is_no_inheritance_!


>I have to say that this is the first time in pretty near a decade I have 
>been writing in and teaching with Ada that Ada hasn't come up with the 
>goods.  Do I labour under some serious misunderstanding, do I have something 
>terribly wrong?

Basically you are making some assumptions based on what you appear to
expect from an object-orientated programming language rather than
looking at the details of how O-O is implemented in Ada 95. Admittedly
the Ada 95 implementation can be a pain in the arse sometimes,
especially if you're used to using C++ and Jave, but there are
generally good reasons for why things are done the way they are. You
need to look at the Rationale to find them out a lot of the time.

>5.   One final thing (for this time anyway ;), why is it that that Ada does 
>not use the intuitive 'object.method' syntax for making calls to and object. 

Go to www.adaic.org and find the Ada 95 Rationale. I believe this is
discussed in there, as are pretty much all of the questions you have
asked to some extent.

>If there are people working on Ada0x then maybe we shoo\uld be putting this 
>forward for consideration.

You haven't been looking at this newsgroup much have you :-)

As David mentioned, it would be worth providing code for this question
rather than your nice class diagrams as the code may tell a different
story.

Re: Ada OO

[John McCabe]

On Tue, 08 Oct 2002 02:17:07 +0000, "Rick Duley"
<rickduley@hotmail.com> wrote:

As a matter of interest, why did you resend this message with a
different title when there was already a discussion on your original
posting (from 4 days earlier) going on?

Re: Ada OO

[tmoran]

> As a matter of interest, why did you resend this message with a
> different title when there was already a discussion on your original
> posting (from 4 days earlier) going on?
  It's also curious that a whole new thread is covering the same ground,
with many of the same explanations - both right and wrong.
Do lots of people have broken newsreaders that only show *some* threads?

Re: Ada OO

[David C. Hoos, Sr.]

Without seeing the actual code, it's very difficult to ascertain why you
are not seeing the results you expect.

Could you supply code in lieu of the cute little boxes which do not
tell us the whole story?

 
----- Original Message ----- 
From: "Rick Duley" <rickduley@hotmail.com>
To: <comp.lang.ada@ada.eu.org>
Sent: October 07, 2002 9:17 PM
Subject: Ada OO


> Hi all
> 
> I believe that I am the last surviving academic Ada programmer in Perth, 
> Western Australia and I am in need of some help.  I am having problems 
> coming to terms with the rationale behind Object Oriented programming in Ada 
> and there is no-one I know in Perth to talk to.  I'm hoping you folk won't 
> mind giving me a hand.
> 
> Perhaps I had better start by explaining my (mis-) understanding of the 
> general principle of inheritance.
> 
> Suppose I have defined an object Pen_Class to have the form:
> 
> +-------------------------------------------+
> | Pen                                       |
> +-------------------------------------------+
> | X     : Integer;                          |
> | Y     : Integer;                          |
> | Color : Color_Type;                       |
> +-------------------------------------------+
> | procedure Move_To(This : in out Pen;      |
> |                   X    : in     Natural;  |
> |                   Y    : in     Natural); |
> | -- move the pen to the specified location |
> | --  without drawing                       |
> |                                           |
> | procedure Draw_To(This : in out Pen;      |
> |                   X    : in     Natural;  |
> |                   Y    : in     Natural); |
> | -- draw a line from the current location  |
> | --  to (X,Y) using the pen's              |
> | --  current color.  the pen's location    |
> | --  moves to (X,Y)                        |
> |                                           |
> | function New_Pen(X     : Natural;         |
> |                  Y     : Natural;         |
> |                  Color : Color_Type)      |
> | return Pen_Access;                        |
> | -- returns access to an initialised Pen   |
> +-------------------------------------------+
> 
> This object should be initialised by New_Pen and all the functionality it 
> should need should be supplied by the other two methods.  Of course, if you 
> want to change Pen Colour in midstream you would have to provide the 
> functionality to do so but let's keep this simple so I can get a handle on 
> it ;)
> 
> Extension of this class to Thick_Pen_Class should, according to me, result 
> in a class having the form:
> 
> +-------------------------------------------+
> | Thick_Pen                                 |
> +-------------------------------------------+
> | X         : Integer;                      |
> | Y         : Integer;                      |
> | Color     : Color_Type;                   |
> | Thickness : Positive;                     |
> +-------------------------------------------+
> | --=== inherited from Pen_Class ===--      |
> | procedure Move_To(This : in out Pen;      |
> |                   X    : in     Natural;  |
> |                   Y    : in     Natural); |
> | -- move the pen to the specified location |
> | --  without drawing                       |
> |                                           |
> | procedure Draw_To(This : in out Pen;      |
> |                   X    : in     Natural;  |
> |                   Y    : in     Natural); |
> | -- draw a line from the current location  |
> | --  to (X,Y) using the pen's              |
> | --  current color.  the pen's location    |
> | --  moves to (X,Y)                        |
> |                                           |
> | function New_Pen(X     : Natural;         |
> |                  Y     : Natural;         |
> |                  Color : Color_Type)      |
> | return Pen_Access;                        |
> | -- returns access to an initialised Pen   |
> |                                           |
> | --=== new in Thick_Pen_Class ===--        |
> | procedure Move_To(This : in out Thick_Pen;|
> |                   X    : in     Natural;  |
> |                   Y    : in     Natural); |
> | -- move the pen to the specified location |
> | --  without drawing                       |
> |                                           |
> | procedure Draw_To(This : in out Thick_Pen;|
> |                   X    : in Natural;      |
> |                   Y    : in Natural);     |
> | -- draw a line from the current location  |
> | --  to (X,Y) using the pen's              |
> | -- current color.  the pen's location     |
> | --  moves to (X,Y).  The                  |
> | -- vertical thickness of the pen is given |
> | --  by Thickness.                         |
> |                                           |
> | function New_Thick_Pen                    |
> |    (X         : Natural;                  |
> |     Y         : Natural;                  |
> |     Color     : Color_Type;               |
> |     Thickness : in Positive)              |
> | return Thick_Pen_Access;                  |
> | -- returns access to initialised Thick_Pen|
> |-------------------------------------------+
> 
> I would expect all the class attributes, the data variables, to be accessed 
> by the methods of the derived class with the overloading providing the 
> polymorphism.  My problems start when this doesn't happen.
> 
> 1.   All the texts I can find which deal in any degree at all with OO in Ada 
> teach that the tagged record in an object declaration should be 'private'.  
> When you follow this line, a derived class does not have direct access to 
> the object attributes of the base class, i.e. _there_is_no_inheritace_.
> 
> 2.   To provide the derived class with access to the object attributes of 
> the base class I have to create user-defined methods in the base class.  
> This has two effects:
>      a) the object attributes of the base class are now effectively public, 
> i.e. accessible (through the user-defined methods) to any client module 
> through 'with' and 'use' -  which effectively negates the act of making them 
> private in the first place;
>      b) having to provide accessibility in this manner emphasises the fact 
> that inheritance did not occur.
> 
> 3.   If the tagged record in the base class is left public and the derived 
> class is in a child package of the package defining the base class, then the 
> base class attributes are accessible to the derived class.  So far so good 
> :)  However, if in a program 'use'ing the child package of 'Thick_Pen' (and 
> not mentioning the base package of 'Pen') I make a call to the routine 
> 'Draw' with an actual parameter of the type 'Pen' I get a compiler error 
> message to the effect that 'Draw' is not visible.  In other words, Thick_Pen 
> has not inherited the operation Draw for 'Pen'  Again, 
> _there_is_no_inheritace_.
> 
> 4.  Further along that line, Thick_Pen does not inherit the type Pen so I 
> cannot declare a Pen (or Pen_Access) unless I 'with' and 'use' the package 
> in which Pen is declared.  This means that making the package in which 
> Thick_Pen is declared a child of the package in which Pen is declared 
> totally useless.  _There_is_no_inheritance_!
> 
> I have to say that this is the first time in pretty near a decade I have 
> been writing in and teaching with Ada that Ada hasn't come up with the 
> goods.  Do I labour under some serious misunderstanding, do I have something 
> terribly wrong?
> 
> 5.   One final thing (for this time anyway ;), why is it that that Ada does 
> not use the intuitive 'object.method' syntax for making calls to and object. 
>    This would mean that (in the case described in section 3) the call would 
> read
> 
> Pen.Draw(To_X => n, To_Y => n);
> 
> and with inheritance this would be accessible through the child package 
> declaring Thick_Pen.  While I'm okay with using the existing syntax, I feel 
> the 'object.method' syntax is more intuitive and in line with OO thinking.  
> If there are people working on Ada0x then maybe we shoo\uld be putting this 
> forward for consideration.
> 
> 
> So, you see, I'm all at sea.  Can someone help me out?
> Thanks
> 
> 
> 
> -------------------------------------------------
> Rick Duley
> 23/209 Walcott St
> North Perth, Western Australia 6006
> mob: +61 040 910 6049
>                                 /-_|\
>                                /     \
>                          perth *_.-._/
>                                     v
> Experience is the worst of teachers
>        It gives you the exam
>                 before it gives you the lecture
> 
> 
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
> 
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 
>