Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site alice.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!alice!bs From: bs@alice.UucP (Bjarne Stroustrup) Newsgroups: net.lang.c++ Subject: `inherited' keyword Message-ID: <6055@alice.uUCp> Date: Sun, 14-Sep-86 20:45:37 EDT Article-I.D.: alice.6055 Posted: Sun Sep 14 20:45:37 1986 Date-Received: Mon, 15-Sep-86 04:47:21 EDT Organization: Bell Labs, Murray Hill Lines: 131 > 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 > . 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.