Re: OO in Ada

[Jim Rogers <jimmaureenrogers@worldnet.att.net>]

Hyman Rosen wrote:

> Jim Rogers wrote:
>  > In C++ this syntax is good for virtual functions
>  > but illegal for static functions. This causes nasty
>  > problems in C++ template construction.
> 
> You don't mean 'virtual' and 'static', you mean
> 'member function' and 'non-member function'. It's
> not so much an issue of nasty problems. It's just
> that having two different notations for calling a
> method means that when you're writing a template
> you have to know which notation to use, which
> limits its genericity.


Thank you. That is just what I wanted to say if I
knew C++ better. Sorry about the error.


> 
>  > C++ (and Java) forbid dispatching based upon the
>  > return type of a function. This is one of the
> 
>> side effects of the 'object.method' notation.
> 
> 
> Your first statement is true, but your second is
> false. Why do you think object.method would prevent
> dispatching on return type?
> 


I think that because the dispatching is always performed on the
type of "object" in object.method. This rule would have to be
seriously modified to dispatch on the return type of a function
(or method in Java's terminology).


>> should be phased out by allowing [member] functions
> 
>  > to be called in the same way as [non-member] functions.
> 
> It will never be phased out, of course, since that would
> destroy millions of lines of code. Someone might come up
> with a reasonable proposal for allowing the method(object)
> notation, though. The problem is the impact this owuld have
> on overloading and name lookup, which is already extremely
> complicated.
> 
> The design issue for C++ is that sometimes you want member
> functions as part of an interface and sometimes you want
> standalone functions. Having a different calling notation
> makes it harder to switch the function from one type to the
> other, because you have to modify all the callers.
> 
> On the other hand, Ada gives the illusion of multiple dispatch
> by allowing several parameters to control dispatching, but then
> forcing them all, at runtime, to have the same dynamic type. I
> suppose some future version of Ada could lift this restriction
> while keeping the same notation, which is good.
> 
> 


I disagree here. Ada does not give the illusion of multiple dispatch.
An Ada subprogram can only be primitive to one type. That characteristic
is determined by the place in the source code where the subprogram
interface is defined. I am not really happy with this design feature,
but it is what it is.

Jim Rogers