cook@hplabsz.HPL.HP.COM (William Cook) (08/03/89)
Recently there has been some discussion on problems in typing methods
that return "self". I want to point out that Eiffel allows these
methods and gives them their most natural typing. Unfortunately,
Eiffel does not seem to be perfect in this respect, in that it allows
some typings that are insecure (see my paper, "A Proposal for Making
Eiffel Type-safe", in the proceedings of ECOOP'89).
Eiffel uses "Current" instead of "self" or "this". It also has a
novel typing construct called _declaration by association_ which
allows a type of the form "like Current" to represent the type of a
method that returns "Current". The example given by Michael T.
Kelley, which was illegal in C++, can be coded in Eiffel. I haven't
run this code, so it may not be perfect. The keyword "is" indicates
the return value type of a method.
class Base
feature
hello is Like Current do
output("hello");
Result := Current;
end
end
class Derived
inherit Base
feature
hello is Like Current do
output("g'day ");
Result := Current;
end
goodbye is do
output("see ya!");
end
end
class Main
feature
Create is
local
d : Derived;
do
d.hello.goodbye; -- type-correct
end;
end
A general "copy" method can also be implemented with the same typing,
by "creating" an object of type "Like Current".
I don't understand Andrew Koenig's conclusion that this behavior
should be illegal because you don't know the type at compile-time. I
thought not knowing the precise type of things at compile-time is
essential to OOP. When working with a variable v:Base one can only
know that v.hello will be an instance of some subclass of Base. But
this is enough because any such object will handle all the messages
defined in Base.
-william cook@hplabs.hp.comvaughan@mcc.com (Paul Vaughan) (08/03/89)
William Cook (cook@hplabsz.HPL.HP.COM) writes: >I don't understand Andrew Koenig's conclusion that this behavior >should be illegal because you don't know the type at compile-time. I >thought not knowing the precise type of things at compile-time is >essential to OOP. When working with a variable v:Base one can only >know that v.hello will be an instance of some subclass of Base. But >this is enough because any such object will handle all the messages >defined in Base. I also don't understand Andrew Koenig's conclusion, but you are not quite correct for c++. When working with a variable Base v; v is most definitely a Base and not a subclass of Base. Only with a variable Base* vp; can you deal with an object which may be a subclass of Base. (Sorry if I'm picking nits.) One of Andrew's arguments had to do with ambiguity when you had references that refered to objects which could be a subclass of the stated type (indefinitely typed). Note that this is also impossible in the current c++. I wrote an article previously (which, from the lack of response, either didn't get out, or was too garbled to understand) that compared indefinitely typed references with pointers. Basically, I don't think there is any ambiguity added with indefinitely typed references that the language doesn't already resolve with pointers. His other argument had to do with overloaded functions. My response to that was that overloaded functions always work on the stated type of their arguments, rather than the actual type, and that there is no ambiguity involved there either. The rule about not being able to overload functions based only on pointer types simply hides this fact. This isn't perhaps the most desirable property in terms of language power, but it is efficient. The only language I know of that allows generic functions with multiple dispatch is CLOS. Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639 Box 200195, Austin, TX 78720 | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan
Paul.Vaughan@mamab.FIDONET.ORG (Paul Vaughan) (08/06/89)
-- Fidonet: Paul Vaughan via 1:363/9 Internet: Paul.Vaughan@mamab.FIDONET.ORG Usenet: ...!peora!rtmvax!libcmp!mamab!Paul.Vaughan