Re: Real OO

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

Jon S Anthony writes:

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

I think the examples which I listed speak for themselves. Do you dispute that
any are semantically equivalent? If so, which ones and why? I assume you are 
talking about 4. (See below).

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

Not sure what you mean here. Classes T and U are not extraneous and no more 
classes need to be defined.

:  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 no different from Ada.

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

I'm sure you're right. I wouldn't know.

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

Reinserting my example 4.
4.   function i (a: T'Class) return T'Class   frozen i: like Current

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

If I understand Jacob correctly, the anchored entity conforms both statically
and dynamically to Current. On that basis, I would say that all the examples
I gave are equivalent.

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

My point here about uniqueness is a minor one but valid nevertheless. However,
I'm not about to lose sleep if you disagree. I guess the Eiffel equivalent to
Ada's multiple controlling operands is something like (assuming the same 
definitions):

5.   function k (a: T; b: T) return T is    k (b: like Current): like Current is
     begin                                   require
       ...                                     Current.conforms_to (b)
     end                                     do
                                               ...
                                             ensure
                                               Current.conforms_to (Result)
                                             end

A little more long-winded but notice the semantics is probably really closer
to what you want because the test on the dynamic type of Result is made after
the routine body: it's nonsense to make assertions about the Result until it
exists.

If either the precondition or the postcondition is not met, an exception is 
raised, as in Ada.

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

I hope you will agree by now that Eiffel and Ada are as flexible as each other
in terms of the mechanisms they offer.

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

Mostly facetious. But I do find it slightly ridiculous to say that there are
multiple controlling operands if it only works if they happen to have the same
dynamic type. (No, I'm not saying that it should be possible for them to be
different). The fact that you get an exception if the types differ is not as
plain as in the Eiffel paradigm, IMO. 


Try to quote a little of what I say. Reinserting what I wrote:

You are referring to catcalls: calls which fail because a descendant class
makes changes which render the call non-polymorphic wrt ancestors. The changes
may be:

a) a type has been redefined to a non-conformant type, or
b) a routine has been made inaccessible due to a change in it's export status.

At first sight, it seems silly to permit such things if they can cause problems
with polymorphism but there is a worthy motivation for providing such flexibility:
allowing reuse of legacy code that does not exactly fit your requirements.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

:>["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

a problem. But flexibility and reuse are regarded as paramount, so the issue
arises. It's an acknowledged problem which is currently being addressed but I 
don't know how. Hopefully, the solution will retain flexibility and efficiently
prevent such calls being made.

:Actually, Eiffel is (clearly) more restrictive here.

Not at all. The problem is that it is more permissive in this area (for
the good reason of allowing reuse of legacy code) and this can cause runtime 
errors. If Ada were just as permissive, it would be a problem for Ada too. 
In Ada, you can't reuse such code that almost meets your needs; you have to 
rewrite it which could be a formidable task.

:  It _tries_ to
:have _less_ things ensured at runtime.

The intended purpose of system-level validity checks is to identify and exclude
at compile time the stuff that would cause runtime errors. If you ensure 
something at compile time, you also ensure it for runtime. (Yes, I know that
few, if any, Eiffel vendors implement it). Don't know what you mean here.
 
:  And the reason it is a problem
:is that Eiffel source does not have as much semantic information in it
:in this area.

What might that be?

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

Please do.

:
:/Jon
:-- 
:Jon Anthony
:Organon Motives, Inc.
:1 Williston Road, Suite 4
:Belmont, MA 02178
:
:617.484.3383
:jsa@organon.com
:

Don.