Re: Real OO

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

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

> Norman H. Cohen wrote:
> 
> :In article <65O34ib-3RB@herold.franken.de>, jhd@herold.franken.de
> :(Joachim Durchholz) writes: 
> 
> :   A classwide routine is, by definition, one whose
> :correctness does not depend on the dynamic types of the objects it is
> :dealing with.
>
>  Apart from the efficiency aspect, I wonder is the eagerness of Ada
> programmers to freeze routines related to the fact that assertions
> aren't available to: - guard against errors in parents being
> propagated into descendant classes, and - correctness in parents
> being compromised in descendants? ;-)

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.
The notion of classwide types is more similar to Sather abstract types
(though there are differences there too), and how they behave wrt to
operations.

> With such an appreciation of OO, you ought to be a big fan of Eiffel!
> 

Or better yet, Ada!  Or Sather...

> :|> 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.
> :
> :(Are you sure it's the DYNAMIC type?  Section 11.4.3 of Meyer's
> :_Object_Oriented_Software_Construction_ seems to suggest that it's the
> :declared type.)

>  No. It's the static type. Further, if you say 'like Current', it is
> the static type of the class in which the routine is defined. The
> purpose of anchored types is to define type dependence and to do it
> once only. The dependence is propagated

Well, now that is odd as Joachim disputes your claim and sites an
ETL reference that it is indeed _dynamic_.


> :It's the "or a type that is a descendant of" that differentiates the
> :Eiffel approach from the Ada approach.
> 
> ... 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.  And what's more, there are several cases where
Eiffel either a) ensures dynamic type integrity with runtime errors or
b) tries to determine this with the infamous system validity check.
(which many (most??) implementations do not even try to do.  Yes, I
know there is/was some attempt to remove this, but the impression is
it is still a problem).

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

617.484.3383
jsa@organon.com