[squeak-dev] Re: Instance variable access in superclasses.

Eliot Miranda eliot.miranda at gmail.com
Wed Nov 26 18:32:59 UTC 2008


On Wed, Nov 26, 2008 at 10:22 AM, Greg A. Woods; Planix, Inc. <
woods at planix.ca> wrote:

>
> 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.


Then choose a different class than SmallInteger to make your point.
 SmallInteger is rather special, an immediate class whose instances are
represented specially by encoding their value in an object pointer, so that
a reference to a SmallInteger *is* the SmallInteger.  In Squeak SmallInteger
is the only such class.  Subclasses of SmallInteger by necessity are normal
objects so that when any of the inherited behaviour is used nonsense results
because the subclass instance's normal pointer is interpreted as a
SmallInteger.

Make your point with any other class.  Using SmallInteger will simply create
cognitive dissonance and defocus the conversation.




>
> 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 --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081126/284fbe32/attachment.htm


More information about the Squeak-dev mailing list