Re: Real OO

[jsa@organon.com (Jon S Anthony)]

In article <DqAyLG.D47@assip.csasyd.oz> donh@syd.csa.com.au (Don Harrison) writes:

> :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.

> In OO software, you would want to define them with their types
> (except that in Eiffel, you assign the operation to a particular
> type - whichever is most appropriate). Otherwise, you would end up
> with spaghetti, IMO.

Hmmm, not much of an argument.  If you really want spaghetti, just use MI.

First, classwide operations are not primitive operations and so do not
constitute the "definition" of the type.  So, even from a s called
"purest" view there's nothing wrong with putting them elsewhere.
Second, when they have more than one parameter (the typical case by
far) which type/calss would they be "assigned" to?  Makes no sense and
is a very artificial constraint.  Third, you do this sort of thing in
Eiffel as well: anytime you are not "just" defining a type (for
example, the "main" routine), you just have to use a contrived class.


> :procedure Op (a: T'Class; b,c: U'Class; d: S'Class);
> :
> :In Ada, I can define this in my specific application as I see fit.
> :
> :Now, in Eiffel you need something like,
> :
> :in Class T       in U           in S
> :frozen Op (      frozen Op(     frozen Op(
> :  b:U,c:U,d:S)     a:T,c:U,d:S)   a:T,c:U,b:U)
> 
> Except that you would only need one of them - not three. Note that in any one
> of these, each formal parameter is effectively classwide, including Current.
> So, you only need one of these, as you would in Ada.

Yes, that's true.


> :  Even with some clairvoyance you'd have trouble as you
> :couldn't know about S when T and U were defined.  So, one possible
> :out would be to subclass them all and put the new frozen features
> :in these new "extraneous" classes and use them instead.
> 
> Hopefully, these comments are no longer relevant.

No, these comments are still relevant.  First, clients can't define
them.  Second, you still need to be clairvoyant (define the operation
in one of the classes - even if it is application specific) or
introduce contrived/extraneous classes.  Another way to look at this
is that classwide operations allow you to take arbitrary universal
views of things - without having to go back and inappropriately fudge
the class definitions.


> [In here, we agreed on something, even if it was only to diasagree :-)]

Actually, we really did agree - thanks to the conformance semantics of
anchored types.


> :This is true in the Ada case as well.  The body is statically checked to
> :ensure that the result is T, of course, but during a runtime dispatch
> :the actual result is checked to ensure its dynamic type conforms to
> :its context.  So, Ada loses nothing here.
> 
> Okay.

Hey, we agree again! ;^)


>[multiple dispatch stuff...]
> :> (No, I'm not saying that it should be possible for them to be
> :> different).
> :
> :Actually, I'm not so sure about this.  I understand why this limitation
> :was made, but certainly CLOS and Dylan folk would say this _should_ be
> :possible.  And they have a point too.
> 
> Is this what is meant by multiple dispatching?

Yes.(tm/Kosh)


> :> The fact that you get an exception if the types differ is not as
> :> plain as in the Eiffel paradigm, IMO.
> :
> :OK, but I don't see this.
>
> Only because it is explicitly stated. Nothing to get too excited
> over, though.

[scratches head] - Nope, still don't see it.  But I infer it's not
a bit deal...


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com