[squeak-dev] Instance variable access in superclasses.

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

2008/11/26 Greg A. Woods; Planix, Inc. <[hidden email]>:

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.
                                       <[hidden email]>