sam@think.COM (Sam Kendall) (09/13/86)
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, and what I would like to
know, is
(1) Does `inherited' work for members other than virtual functions? It
certainly should. 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.
(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.
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.
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".
---
Sam Kendall sam@Think.COM
Thinking Machines Corp. ihnp4!think!samkeith@cecil.UUCP (keith gorlen) (09/13/86)
What is "C+-", and how can I get a copy of the specification?
Thanks!
--
---
Keith Gorlen
Building 12A, Room 2017
Computer Systems Laboratory
Division of Computer Research and Technology
National Institutes of Health
Bethesda, MD 20892
phone: (301) 496-5363
uucp: {decvax!}seismo!elsie!cecil!keithbs@alice.UucP (Bjarne Stroustrup) (09/15/86)
> 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.