Xref: utzoo comp.lang.c++:4256 comp.lang.eiffel:345
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!milano!cadillac!vaughan@mcc.com
From: vaughan@mcc.com (Paul Vaughan)
Newsgroups: comp.lang.c++,comp.lang.eiffel
Subject: Re: Implementing virtual functions that return reference to self
Keywords: declaration by association, self, static typing
Message-ID: <2045@cadillac.CAD.MCC.COM>
Date: 3 Aug 89 14:49:13 GMT
References: <8975@thorin.cs.unc.edu> <7131@microsoft.UUCP> <7137@microsoft.UUCP> <9694@alice.UUCP> <3685@hplabsz.HPL.HP.COM>
Sender: news@cadillac.CAD.MCC.COM
Reply-To: vaughan@mcc.com (Paul Vaughan)
Followup-To: comp.lang.c++
Organization: MCC VLSI CAD Program
Lines: 44
In-reply-to: cook@hplabsz.HPL.HP.COM (William Cook)

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