On 25-Nov-2008, at 11:32 PM, Igor Stasenko wrote:

> 2008/11/26 Greg A. Woods; Planix, Inc. <woods at planix.ca>:
>>
>> On 25-Nov-2008, at 10:45 PM, Igor Stasenko wrote:
>>>
>>> My understanding of inheritance is different, in short:
>>> A subclass of particular class is a _specialization_ of base class,
>>> not  _expansion_.
>>
>> Well when you're defining the behaviour of objects in an OO system  
>> there's
>> not really any difference between "specialization" and "expansion"  
>> -- the
>> subclass is _adding_ changes to the definitions given in the  
>> superclass.
>> Perhaps the changes will over-ride a behaviour in the superclass,  
>> or modify
>> it in some way, but fundamentally a subclass is always adding  
>> something to
>> the superclass in order to create the new subclass it defines.
>>
>
> No, specialization and expansion having really different meanings, if
> you consider a class, like SmallInteger.
> Following your understanding, one may want to expand a SmallInteger
> class by subclassing it and providing additional behavior.
> Following my understanding, SmallInteger class is highly specialized
> class, up to the point that its impossible to specialize it further.

What you say is true, but irrelevant to my point.

If you want to create a more specialized subclass of SmallInteger you  
must _add_ code by defining that new subclass.  A subclass always, by  
definition, adds new additional code to the class it inherits from.

Here I'm looking at the actual process of defining a subclass.   
Literally and figuratively.  In Smalltalk-80 a subclass always adds  
code to the class it inherits from, regardless of whether the intent  
is to create a specialized form of the superclass or to create an  
expanded form of the superclass.

Sorry, I probably should have been more explicit in the first place  
about the perspective I'm seeing this issue from.


> Of course i know it. Just a small(talk) correction: classes are
> objects as well and having state as well.

Sure, but that's just a feature of the implementation that comes out  
of the goal to have _everything_ be an object.  That's just the way  
the system describes itself to itself to keep the VM small and simple  
and primitive and perhaps also in some minor way to try to express the  
system within itself in the same way lisp does.  It does help show  
that the design is complete and elegant too of course, and in many  
ways it perhaps makes the implementation easier to design, work with,  
and even use.


>> From "The Early History of Smalltalk" by Alan Kay
>
> 1. Everything is an object
> 2. Objects communicate by sending and receiving messages (in terms  
> of objects)
> 3. Objects has their own memory (in terms of objects)
> ----
> 4. Every object is an instance of class (which must be an object)
> 5. The class holds the shared behavior for its instances (in the form
> of objects in a program list)
> 6. To eval a program list, control is passed to the first object and
> the remainder is treated as its message
>
> so, where in these statements you find anything about inheritance, or
> something where it says that subclass(es) should have any assumptions
> about the ways how superclass is storing its instances in memory, and
> therefore a subclass allowed to directly manipulate the object's state
> without consulting with superclass?


Indeed you don't find anything about inheritance there of course.   
It's not relevant in that context.

Inheritance is an additional feature of Classes, one which adds to an  
OO system.  There were, IIRC, earlier Smalltalks which didn't have  
inheritance, but Smalltalk-80 does, in the form of subclassing.  To  
quote directly from the blue book (p. 56):

	"Lack of intersection in class membership is a limitation on design  
in an object-oriented system since it does not allow any sharing  
between class descriptions.  [[....]]  If class memberships are not  
allowed to overlap, this type of partial similarity between two object  
cannot be guaranteed by the system."

I.e. you could sort of create a subclass by simply copying the whole  
class definition you wish to inherit from, then modify it to your  
liking (this has been done an infinite number of times in uses of non- 
OO languages!).  However then you lose the support of the system to  
maintain the relationship between the shared parts of the superclass  
definition(s) and the subclasses that inherit from it (or indeed even  
just between the superclass and its sole subclass in the case where  
the superclass is not actually an abstract class).

The price you pay of course for the assistance of the system in this  
way is that maintainers of the superclass(es) must now take into  
account the needs of subclass(es), both existing and potential future  
ones too; eg. instance variables (and everything else) defined in the  
superclass are also actually part of the subclass.  TANSTAAFL

Subclassing is just a way of appearing to dynamically copy code and  
then allowing for controlled ways to modify it and add to it.  Again  
the free lunch is taken away by the need for the current  
implementation to recompile subclasses and potentially also fiddle  
with all object instances of those subclasses when certain attributes  
(such as instance variables) are changed in the superclass definition.

This essay is interesting in this context, and perhaps even slightly  
relevant to the whole thread:

	"The Dreaded Super" by Kent Beck
	first published June 1992 in Smalltalk Report
	http://books.google.ca/books?id=Y7FwNB4GV4EC&pg=PA81

-- 
					Greg A. Woods; Planix, Inc.
					<woods at planix.ca>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081126/06d7eb19/PGP.pgp