🚀 go-pugleaf

> From: sam@think.COM (Sam Kendall)
> Newsgroups: net.lang.c++
> Subject: `inherited' keyword
> Organization: Thinking Machines, Cambridge, MA
> 
> I just read a draft of the C+- specification from Apple.  It mentions a
> keyword `inherited' as "a proposed addition to C++ that has not yet been
> adopted by AT&T," used (in C+-) as follows:
> 
> 	inherited::virtual_function
> 
> This gets you the virtual function belonging to the nearest superclass.
> What is not mentioned in the C+- document,

I'd like to comment on this. C+- was intented as an intermediate stage between
C and C++ with special features for accessing the Mac Application Environment.
The intention was to make it into a full C++ as soon as possible. As far as I
know the project was discontinued in favor of a full C++ in/for the MacApp.

I don't like the idea of ``a intermediate stage'' at all. It is an open
invitation to incompatibilities. How recent is that document? If it is less
than two months old I'd like a copy.

However, I will comment on ``inherited'' as if it was a proposal for a new
feature for C++. 

First a C++ example:

	struct base { virtual f() { do_something(); };

	struct derived : base { f() { do_something_else(); base::f(); };

This works.

Using the proposed ``inherited'' that example would look like this:

	struct base { virtual f() { do_something(); };

	struct derived : base { f() { do_something_else(); inherited::f(); };

The difference is that to write the call of base::f() the C++ programmer must
know that ``base'' is a base class of ``derived''. That is not neccesary using
``inherited''. Inherited is ``borrowed'' from Apple's Object Pascal and is their
name for Smalltalk's ``superself''. The argument for ``inherited'' over C++'s
explicit qualification is that
	(1) you need to know less to use it.
	(2) consequently, you cannot make a mistake by
		(a) mentioning the wrong base class, or
		(b) changing base class for ``derived'' without appropriately
		    changing the code to reflect that.

This is all reasonable. The counter arguments are:

	(1) C++ has a facility for acessing members of a base class,
	    and one should not add a new facility to a language simply because
	    it is marginally better in some cases. ``inherited'' adds no new
	    functionallity, only a little convenience (costs: a keyword, and
	    bulk to manuals, tutorials, and compilers).
	(2) I knew about ``superself'' when I designed the C++ explicit
	    qualification notation. The problem with ``superself'' is
		(a) it is a separate mechanism for accessing members of
		    a base class, not a general naming mechanism (as the
		    base::f notation is.
		(b) it does not extend to multiple inheritance (Smalltalk
		    proposals (and implementations?) have introduced the
		    equivallent to C++'s notation to cope. For example:

			struct A { f(); };
			struct B { f(); };
			struct C : A : B { f() { A::f(); B::f(); } };

Consequently, I do not see sufficient reason for adding ``inherited'' to C++
and have no plans of doing so. It may seem callous not to consider the fact
that people at Apple like ``inherited'' and has experience with it sufficient
reason to include it, but such ``kindness'' is the road to a giant language.

> and what I would like to know, is
> 
> (1) Does `inherited' work for members other than virtual functions?  It
>     certainly should.

The C++ notation handles all names properly.

>     If static virtual data items are allowed in C++
>     (are they?  I couldn't find anything in the ref man that prohibits
>    them) then inherited should work for them, too.

There are no virtual data in C++; there does not for the moment appear to be
a sufficient agreement on what ``virtual data'' ought to be to include the
concept.
 
> (2) What is the current status of this construct?  Something like it is
>     certainly needed to make it easier to do a Smalltalk-like
>     send super.

Even given the ``base::f'' notation?

> John Rose, a co-worker of mine, came up with a syntax for send super
> <same message>.  It is just `continue()' called as a function; used
> inside a member function `f', it calls the same thing as
> `inherited::f()', and works for non-virtual as well as virtual
> functions.

Plain ``continue()'' has the problem of only handling call of a base class
function of the same name. The following case is possible in C++ as currently
implemented, but not with ``continue()'':

	struct A { f(); g(); };
	struct B : A { f(); g(); };
	B::f() {
		A::f();	// A's f
		A::g();	// A's g
	}

> A general point: the `continue' keyword is available and could be used
> in place of `inherited'.  It is no less clear than `inherited' --
> `inherited' is really the wrong word here, since you use `inherited'
> for precisely those things which were NOT inherited.  I suppose
> `inherited' is supposed to stand for "would have been inherited".
> `continue' can be thought of as meaning "continue up the inheritance
> tree".

In addition it might be noted that the following works:

	struct A { f(); };
	struct B : A {};
	struct C : B { g() { B::f(); } };

The notation B::f finds A::f since B inherited f from A.