Path: utzoo!attcan!uunet!jarthur!usc!apple!rutgers!pyrnj!esquire!yost
From: yost@esquire.UUCP (David A. Yost)
Newsgroups: comp.lang.eiffel
Subject: Re: Extension of STRING class
Message-ID: <2088@esquire.UUCP>
Date: 15 Jun 90 14:36:13 GMT
References: <1990May25.000500.7492@asterix.drev.dnd.ca> <120019@gore.com> <1713@prles2.prl.philips.nl> <487@tetrauk.UUCP> <2084@esquire.UUCP>
Reply-To: yost@esquire.UUCP (David A. Yost)
Organization: DP&W, New York, NY
Lines: 46

In article <2084@esquire.UUCP> yost@esquire.UUCP (I) write:
>An set of `equivalent' classes would be classes that
>were related by enhancement.  If classes A and B are
>equivalent, then
>
>   x: A;
>   y: B;
>   z: C;
>
>   x.f
>
>is permitted as long as f is defined A or in only one
>of the other equivalent classes.

This won't fly because if someone comes along and
declares a class D with feature f, the code is no longer
unambiguous.  It's got to be something more like this:

   x.f

is permitted, as usual, only if f is defined A.

I also said this:
> If f is not defined in A but is defined in B and C,
> then there would need to be a syntax to specify which
> feature f to apply.

Which I now revise to:

If f is defined in B (whether or not it is also defined
in A or C) there would need to be a syntax for applying
feature f of B to x.  For example:

   x%B.f

Maybe before you can use this syntax, you should have to
declare somehow that you believe B to be equivalent to A.

This proposal does feel a bit like type casting in C and
C++, but I hasten to point out that it differs in that it
is typesafe, and that it is similar only to a subset of the
cases in which type casting is used.

 --dave yost
   yost@dpw.com or uunet!esquire!yost
   Please ignore the From or Reply-To fields above, if different.