Re: Real OO

[jhd@herold.franken.de (Joachim Durchholz)]

ncohen@watson.ibm.com wrote 22.03.96 on Re: Real OO:

> ...a specific type as an Eiffel reference whose dynamic type is known to be
> identical to its static type.  A method call can be far more efficient if
> this knowledge is conveyed to the compiler, and it is common in practice
> for this knowledge to be available.

The Eiffel paradigma is that it should *not* be possible to fix a formal  
parameter's dynamic type to its static types. Such a thing is considered  
an unnecessary limitation introduced on the routine, for efficiency  
reasons that aren't even valid because a compiler can determine wether  
such an optimization is possible.
In fact, all Eiffel literature on the subject strongly encourages compiler  
writers to replace dynamic cally by static calls whenever possible, and to  
inline code wherever it makes sense.

> For a one-parameter subprogram, the effect of a classwide subprogram
> could be achieved by a dispatching subprogram that is never overridden.

Agreed.

> Making it classwide simply documents the fact that the algorithm does not
> depend on the tag of the parameter, and causes the compiler to catch any
> attempt to override.

This assumes that the writer of a module knows that his routines never  
need to be overridden. While this may be true when writing a program with  
a fixed and well-understood task, this isn't true when writing libraries,  
or when programs are modified in the future and in ways that weren't  
anticipated.
Considering the fact that fixed and well-understood tasks don't need OO  
(structured programming and functional decomposition should suffice for  
this type of tasks), this argument gains some weight.

> The real power of a classwide program arises with
> multiple parameters.  In Eiffel, dispatching is controlled by the one
> object whose method is invoked (the x in x.f()).  In an Ada dispatching
> subprogram, there can be multiple parameters controlling the dispatching.
>
> [Omitting details on dispatching based on the dynamic type of multiple
> parameters]

The type of dispatching noted here can easily be achieved with anchored  
types in Eiffel. In an Ada-style notation, this would look as follows:

  function Corresponding_Parts_Equal
    (Self: Shape_Type; Other: like Self)
  return Boolean

The "like Self" part requires Other to have the same dynamic type as Self,  
or a type that is a descendant of Self's type.

I'm not sure wether this is enough to handle all cases that arise in  
practice, but it goes a long way.

BTW I see serious problems with the Congruent function given.

Consider descandant types "Filled_Circle", "Hatched_Circle" etc. - with  
the understanding that these don't have any new geometric properties that  
should influence Corresponding_Parts_Equal or Congruent.
First of all, it would be necessary to define a Corresponding_Parts_Equal  
function for each pair of Circle_Type descendants - this can become quite  
a formidable task if the number of direct and indirect descandants grows.
In addition, the Congruent code will break - Shape1'Tag and Shape2'Tag  
will not be equal, making Congruent return false even if a Filled_Circle  
and a Hatched_Circle actually have equal corresponding parts.


-Joachim

--
Im speaking for myself here.
## CrossPoint v3.1 ##