Re: Real OO

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

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

> Jon S Anthony writes:
> 
> :In article <DpBsG4.MIE@assip.csasyd.oz> donh@syd.csa.com.au (Don Harrison) writes:
>...
> :I think you are confused here.  Don't start thinking that Eiffel's
> :"frozen" feature is the equivalent of a classwide operation.  It is
> :not.  Classwide operations are more general and flexible and cover
> :other sorts of ground beyond what you have with simple frozen features.
> 
> Yes, Eiffel's frozen routines alone are not the equivalent of Ada's classwide
> operations. The Eiffel analogue is a combination of:
> 
> a) frozen routines, which make a routine classwide for Current, and
> b) parameters, all of which are classwide by default, and
> c) results of functions, which are classwide by default.
>
> This provides the same generality and flexibility of Ada's classwide
> operations.

I don't see how.  For one thing clients can't define such things
without introducing gratuitous/extraneous classes (I would say this is
one of the more important uses).  For another, you need some
clairvoyance when designing a class in determining the set of features
to freeze in order to use them in these sorts of combinations
elsewhere.  This is a real "no no" ala C++ "virtual" tagging.  From
what I can tell, Eiffel just plain does not have the equivalent
flexible capability here.  Again, class wide types and their
operations are more like Sather abstract types and ops on them.
Eiffel does not have these...


> equivalent operations in Eiffel and Ada. They are dispatching wrt
> some parameters and classwide wrt others (eg. 2. below).
>...

Hmmm, actually as I understand the semantics of Like Current, I would
say that in general these examples are _not_ equivalent.  Like Current
seems to require the type of the actual/result must be the same as the
type of the specific object on which the particular invocation has
been made.  No such restriction is true in the Ada case - the result
can be any type in the tree rooted at T.

Actually, this is a little fuzzy, since there is some other talk in
ETL where I think you could read Like Current as allowing for anything
_conformant_ to the type of the object on which the invocation has
been made.  Anyone know the real scoop??

> :> ... and makes the Eiffel approach more flexible (and robust: Ada raises a
> :> Constraint_Error exception if the dynamic types of multiple controlling
> :> operands differ RM95 3.9.2 (16) ).
> :
> :Not if you are using classwide types and operations.  You can't even
> :_have_ multiple controlling parameters in Eiffel so it is certainly no
> :more "flexible" here.

> Nor would we want to. One operand, Current, is more than adequate to
> convey the information in accordance with the OO principle of
> uniqueness.

Just like I said, Eiffel is less flexible here (but not in some ground
shaking way.)


> In Ada, with the second, third, fourth, ... and nth
> operands of the same specific type controlling dispatching, by the
> time the compiler gets to the end of the routine signature, it is
> rolling it's eyes and crying: "Good grief, I heard you the first
> time!!!"

Don, are you really this clueless or are you just being facetious?
The reason I say this is that the above doesn't even work as a joke,
because it is rooted in an error (instead of a clever observation).


>["catcalls" and system validity check problems...]
> I suspect it's only a problem in Eiffel because other languages
> don't provide that flexibility. Obviously, if Eiffel were more
> restrictive, it would not be

Actually, Eiffel is (clearly) more restrictive here.  It _tries_ to
have _less_ things ensured at runtime.  And the reason it is a problem
is that Eiffel source does not have as much semantic information in it
in this area.  Ada OTOH, does and has no problem here at all.  There
was a rather good discussion of this stuff about a year ago.  Maybe I
can dig that up.

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

617.484.3383
jsa@organon.com