Re: Choice of OO primitives in Ada95

[bobduff@world.std.com (Robert A Duff)]

In article <Dn42C3.21u@assip.csasyd.oz>,
Don Harrison <donh@syd.csa.com.au> wrote:
>Ray Toal wrote:
>:Requiring 'tagged' is a GOOD THING!  Inheritance weakens encapsulation.
>
>Not sure what you mean by this. Inheritance is no weaker or stronger in languages
>(such as Eiffel) which map classes onto the encapsulation mechanism.

He didn't say "inheritance" is weaker, he said "encapsulation" is
weaker.  That's clearly true -- when you see a function call that cannot
dispatch, you know for sure exactly what it does.  When you see a
dispatching call, it might go off and do something you've never heard
of.  If there's no dispatching, then a single abstraction is completely
encapsulated, whereas with dispatching, an overriding function can sneak
in and do buggy things.  Dispatching is a powerful feature, but it has
this cost.  If you use dispatching when you don't need it, you are
paying that cost without getting any benefit.  Therefore, it makes sense
to give the programmer the choice.  Note that Eiffel seems to agree with
this, to some extent -- otherwise, the "frozen" (or whatever it's
called) thing wouldn't exist.

Of course, the counter-argument is that you don't always know ahead of
time when you might need dispatching.

I'm not sure I agree with Ray Toal, though, that requiring "tagged" is a
Good Thing.  Even without that rule, Ada still gives you control over
whether things dispatch, on a call-by-call basis.  So, I view "tagged"
as simply an efficiency hack.  Efficiency is a Good Thing, too, though.

>Yes, it's called Eiffel and it's great having such flexibility! :-). One aspect
>of that flexibility is that, if, one sunny day, you decide you need to extend a
>type you go right in and do it and don't have to touch the original.

Well, that's not *really* true.  You quite often have to go back and
change the original, because you're doing something new that conflicts
with assumptions made by the original.

>... In Ada, you
>have to go back and redefine the type to make it tagged. The impact of this may
>be limited to that - don't know, haven't thought about it - but you shouldn't have
>to redefine something to reuse it.

I pretty much agree with that.  You can, of course, make all your types
tagged in the first place, and then you won't have that problem.

>:                                            Whether or not a type
>:should be tagged is a DESIGN decision; I totally disagree that it
>:should be an implementation decision.  By the way a compiler can not
>:in general determine if the "type is extended elsewhere" since in
>:Ada extensions can appear in other compilation units.
>
>I can't think offhand of a suitable way of dealing with this but that isn't to
>say it's impossible. 

It is clearly possible to do at link time, and clearly impossible at
compile time, given separate compilation.

>You don't have to do it that way. You can use (for example) a synonym construct like
>
>  procedure P, Q (X: T) is begin R(X); end P, Q;
>
>and redefine Q for extensions of X.

Yes, that's another reasonable way to do it.

- Bob