Re: Real OO

[stt@henning.camb.inmet.com (Tucker Taft)]

One correction, and one comment...

Don Harrison (donh@syd.csa.com.au) wrote:

: In case anyone is confused about how Eiffel's and Ada's parameter mechanisms 
: compare, the following hopefully summarizes them:

: SUPPLIER                                          CLIENT            BINDING
: --------                                          ------            -------
: Assuming:

: Ada:
: type A_TYPE is private    -- tagged               m: A_TYPE;
: type B_TYPE is private    -- tagged               mc: A_TYPE'Class;
:                                                   n: B_TYPE;
:                                                   nc: B_TYPE'Class;

: Eiffel:
: class A_TYPE ... end                              m: A_TYPE
: class B_TYPE ... end                              n: B_TYPE

: Case1
: -----
: Ada:
: procedure f (a: A_TYPE)                           f (m);            static
:                                                   f (mc);           dynamic

: But if f not defined in same spec:
:                                                   f (m);            static
:                                                   f (mc);           static

f(mc) is not legal in Ada.  You can't pass a dynamically tagged operand
like "mc" to something that expects a specific type like A_TYPE.

This rules helps to avoid confusion about what is and what is not
dynamically bound, and to avoid implicit "truncation" or "slicing"
as it is sometimes called.  Unintended "slicing" is a relatively common 
source of bugs in C++.

: Eiffel (inside A_TYPE):
: f                                                 m.f               dynamic

: ...

: Conclusion:

: Ada:
:   - more efficient, but
:   - manual optimisation places a burden on developer

This really isn't optimization, in my view.  It is simply
distinguishing between a specific type and a set of types.
I doubt if the programmer is even thinking in terms of
optimization.  I presume they are more thinking in terms
of correctness and maintainability.

:   - reduced flexibility/reusability

I don't agree with this.  When dynamic binding is used willy-nilly
and without explicit intention, you don't get flexibility, you get 
a maintenance nightmare.  You can exactly match the Eiffel "flexibility"
by using dynamic binding explicitly, so the only difference is whether
the default is dynamic or static binding.  This has more to do with
readability and intent, than with more or less flexibility.

The rule for what is dynamically bound in Ada is basically just this:

  You get dynamic binding only when passing a class-wide controlling 
  operand to a dispatching operation.

Everything else is statically bound.

: ...
: Don.

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA