Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!usc!apple!voder!procase!roger
From: roger@procase.UUCP (Roger H. Scott)
Newsgroups: comp.lang.c++
Subject: Re: renaming (perhaps better titled "aliasing"?)
Message-ID: <158@logo.procase.UUCP>
Date: 3 Jun 90 03:30:59 GMT
References: <156@logo.procase.UUCP> <CLINE.90Jun2011023@cheetah.ece.clarkson.edu>
Reply-To: roger@procase.UUCP (Roger H. Scott)
Organization: PROCASE Corporation, Santa Clara, CA
Lines: 39

In article <CLINE.90Jun2011023@cheetah.ece.clarkson.edu> cline@sun.soe.clarkson.edu (Marshall Cline) writes:
>In article <156@logo.procase.UUCP> roger@procase.UUCP (Roger H. Scott) writes:
>
>> It seems like a reasonable generalization of the syntax (and semantics?) of
>> pure virtual functions would be to allow:
>>     struct Thing1 : public AbstractThing, public Thing1Implementation {
>>	redefine void f() = do_that_there_f_stuff;
>>     };
>
>Hmmmm.  But what does this do to the conformance requirement of subtypes?
>You want to change the language, the only benefit of this new language
>feature being to avoid at most one virtual function call, and the cost of
>the feature being that publically derived subclasses will no longer will
>have the same public interface.  Hmmmm.
How do you figure?  I think you are reading something into my proposal
that is not there.  In the example above
Thing1Implementation::do_that_there_f_stuff() *is* inherited by Thing1 (not
that this fact is likely to be relevant, given that Thing1Implementation is
not by itself very useful or interesting), so:

	Thing1 *p = ...;
	p->do_that_there_f_stuff();

would be allowed, as well as

	p->f(); // which happens to do the same thing

>
>I know that subtype conformance isn't important to everyone, but please
>don't break it for those of us who like to say `is-a'!
I wouldn't dream of messing with such a thing.  I don't have any problems with
the type system, and am not out to change it either deliberately or accidentally.

By the way, you are wrong about "the only benefit ... being to avoid one virtual
function call".  There is also argument passing, which in C++ can be non-trivial
in the case of objects with X::X(const X&) defined.  For instance, imagine a
little reference-counted pointer class.  Everytime an instance of such a
class is passed to a function the object is copied and the reference count must
be bumped.  Then there's returning values ...