Re: Real OO

[donh@syd.csa.com.au (Don Harrison)]

Matt Kennel writes:
:: jsa@organon.com wrote 19.04.96 on Re: Real OO:
:
:: > Simply this:  Classwide operations can be defined anywhere by anyone.
:: > They do not have to be defined along with the primitive types in
:: > their packages.
:
:And how is this different from Eiffel?
:
:class A is
:
:end
:
:class B is
:
:end
:
:class C is
:
:end
:
:
:class ANYWHERE_BY_ANYONE is
:
: this_is_what_ada_calls_a_classwide_operation(a:A,b:B,c:C) is ... end;
:       
:end

That's true, and there's nothing wrong with it. I take back my comment about
spaghetti, however, note that a benefit of the 'Ziggy' approach is that the
spaghetti may be unraveled so that the impact of redefining attributes of a class
may be more easily seen because the operations which use it are shown in the
merged view of the class.

BTW, a further clarification. I wrote:

: Comparison with Eiffel:
:
: 1) Each parameter to an operation has the same status: there is no Current object
:    and attributes of each parameter object may be updated directly
:
:    eg. a.y := ...
:        b.x := ...
:
:    This is more permissive than Eiffel.

Before I'm accused of breaking encapsulation, what I mean is that reattachment
validity would be as follows:

  do_y (a: A; b: B) is
  require
    a.p > 0 and
    b.s > 0
  do
    a.p := ...                     -- legal
    a.p.k := ...                   -- illegal!!!
    some_op (a.p.k)                -- legal
    a := b                         -- legal
    a := b.t                       -- legal
  end

In other words, it's the same as Eiffel, except that the privileges of Current
to update it's own attributes directly is extended to other parameters (because 
there are effectively multiple Currents) and you can use (the equivalent of) 
Current in assignments (without using wrapper classes?).

I think that a general benefit of the design would be that there would be fewer 
situations where extraneous wrapper classes would be required thus enabling 
greater modelling integrity in that classes would tend to represent genuine 
abstractions rather than contrived ones conceived solely to work around the 
pure OO model.

WRT, multiple dispatching, it should be noted that although it is the default,
runtime efficiency is not compromised for equivalent Eiffel calls because they 
would be optimised statically into simpler calls depending on whether each 
parameter type is extended:

a) simpler multiple dispatching calls (where one or more is extended)
b) single dispatching (where only one parameter's type is extended) 
c) statically bound calls (where no parameter's type is extended).

Of course, this is more work for the compiler/linker.

Note that in this model, the class is retained as the sole means of encapsulation
(unlike Ada, Dylan?). However, operations may be grouped (together with classes) 
outside the language in clusters just as in Eiffel.


Some are no doubt thinking that I want to invent a new language. Not so. What I
would like is for such a model be considered for Eiffel if it is considered 
a significant improvement. I think it would be, but that's just my opinion
and there may be problems that I have overlooked. It is certainly not my intention 
to create a splinter language from Eiffel. Eiffel is a terrific language but
still has flaws. What I would like to do is invite discussion on the idea in 
comp.lang.eiffel and if it is deemed a significant improvement, then a formal 
proposal could be made to NICE.

If translation from Eiffel 3 to 'Ziggy' is straightforward, as it should be,
then the idea of it becoming a future version of Eiffel has some credibility.

                    ///
Don.               (o o)
=-=-=-=-=-=-=-=oOO=-(_)-=OOo=-=-=-=-=-=-=-=-