Re: OOD in Ada?

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

"David Crocker" <dcrocker@eschertech.com> wrote in message
news:3d135676$0$8511$cc9e4d1f@news.dial.pipex.com...
> I know that Ada95 tries to support O-O development, but from my
perspective
> as an OO developer but Ada novice, it appears to me that any attempt to
> implement a large OO design in Ada will run into the following problems:
>
> 1. The infamous "withing" problem (i.e. it is not possible to declare 2
> classes A and B, each in its own package, such that A has a method taking
a
> paremeter of type "access B", and B has a method with a parameter of type
> "access A"); and
>
I'm not sure that this is somehow or other essential to OO Programming.
Perhaps you just need to consider another way of doing it rather than try to
force an idiom from another language onto Ada. If you really need to do
that, you could probably do some version of deriving A and B from some lower
level type(s) that declares an access type to the underlying type(s)'Class -
then A and B can with the base types and get the access types they need.

A solution does exist - I just don't think I'm convinced that you really
need to do that and that failure to find a way means you can't do large OO
designs in Ada.

If you absolutely insist it is essential, try this:

package Base_Class is
    type Base_Type is tagged private ;
    type Base_Ptr is access all Base_Type'Class ;
    -- etc...
private
    type Base_Type is tagged null record ;
end Base_Class ;

package Base_Class.A is
    type A is new Base_Type with private ;
private
    type A is new Base_Type with record
        B_Ptr : Base_Ptr := null ;           -- Can point to any B without
"with"
    end record ;
end Base_Class.A ;

package Base_Class.B is
    type B is new Base_Type with private ;
private
    type B is new Base_Type with record
        A_Ptr : Base_Ptr := null ;
    end record;
end Base_Class.B ;


Iyou're familiar enough with Ada and OOP, you should be able to figure it
out from here... (And no, they don't both need to derive from the same base
type and they don't need to be child packages of the base class.)




> 2. The lack of a "dot" notation (or anything similar) for calling a member
> method, making the code hard to read and hard to determine where dynamic
> binding may be taking place.
>
This is just a syntax thing - one debated here a number of times in the
past. I don't find it essential or hard to read or anything like that. But
then, I'm used to looking at it from "Method (Object)" perspective rather
than "Object->Method" form. Whatever you are used to is going to make the
other way seem "Bad". If you decide to simply Get Over It and work with the
syntax that exists, you'll find it is no more confusing or difficult than
what you are used to.

It certainly won't stop you from implementing any large OO designs and if
you take the language as a whole, I think you'll find you gain lots of
benefits from using it that outweigh whatever downsides there may be to
having to learn & use something that is "Different". (Think of the benefits
you get from things like tasks, protected types, generics, etc. Isn't that
worth a little change in the syntax you are used to?)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com