Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!abvax!iccgcc!klimas
From: klimas@iccgcc.decnet.ab.com
Newsgroups: comp.lang.c++
Subject: Re: Smalltalk-like classes
Message-ID: <1091.26fe3758@iccgcc.decnet.ab.com>
Date: 24 Sep 90 21:41:59 GMT
References: <57379@microsoft.UUCP> <1990Sep13.011214.24799@cs.columbia.edu> <1990Sep13.061908.1032@kth.se>
Lines: 44

In article <1990Sep13.061908.1032@kth.se>, d87-mra@dront.nada.kth.se (Magnus Ramstr|m) writes:
> In article <1990Sep13.011214.24799@cs.columbia.edu> kearns@cs.columbia.edu (Steve Kearns) writes:
>>One of the biggest pains of smalltalk-like classes is that 
>>to understand one class may require scanning four or five classes
>>(the inherited ones).  This is neccessary to find out all the functions
>>and variables that make up a derived object.
>>
>>This goes against one of the fundamental principles of object oriented
>>programming:  a class encapsulates all the functions and data that comprise
>>an object.  
>>
> Correct, but one "class level" defines properties added to, deleted from or
> replacing properties in the superclass(es). The class consists of this
> and inherited properties.
>>
>>....
>>A better solution seems to be the following: soon we will all be using
>>nifty class browsers.  I would suggest that these class browsers
>>automatically copy the inherited items (and their documentation,
>>please) into the subclass with the inherited keyword, or else in
>>italics, or prefixed with the superclass name.
>>
>>The benefit of all this, I repeat, is that one would have to look at
>>exactly 1 class to understand 1 class.  
> 
> This is a good idea, providing that only the documentation and absolutely
> not the implementation is copied. The subclass has no interest what so ever
> in the implementation of superclass methods, only the interface. When
> creating a subclass it is valuable to know what is already implemented. When
> implementing new methods, there is no differance between messages it can
> send to super and messages it can send to any object accessible from the
> method.
	A bit of advice based on evolutionary Smalltalk history.
	The kind of functionality you are describing is available in
	Smalltalk with a thing called a "flattener goody".  It basically
	adds the ability for the Class Hierarchy Browser to show everything
	inherited by a particular class.  Practical experience shows that 
	the use of hierarchy flatteners becomes analogous to being hit in the
	face with a fire hose.  If you get a significant hierarchy, there is so
	much stuff there at once that it becomes more difficult to work with.
	Go ahead and implement it but if your experience is anything like we've
	seen, the usability of the system will go down.  That's why most ST
	users I know who have played with flatteners have abandoned them after
	a while and why it isn't provided on off-the-shelf Smalltalks anymore.