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.

> Or to paraphrase the Blue Book, allowing intersection in class membership is
> the basic mechanism used to allow code sharing between class descriptions.
>  Smalltalk-80 of course doesn't allow multiple inheritance, just plain
> subclassing.
>
>> If you look from a user's point of view (outside a class), you could
>> only send a messages to it. So, for you, as for user its not relevant
>> where an object holds its state - you only interested in its
>> behavior/interface.
>
> You don't send messages to a class -- you send messages to objects which are
> derived from a class, i.e. which follow the behaviours defined by the class.
>
>> As for subclass - a subclass interested in inheriting same interface
>> as base class. Inheriting a state information having a little
>> importance, its just an implementation detail for outside user of
>> class, because anyways he unable to operate with this state directly.
>
> Classes don't have state -- objects have state.  An object which has been
> derived from a subclass gains definitions about its state from _all_ of the
> classes in the class hierarchy which the subclass belongs to.
>
Of course i know it. Just a small(talk) correction: classes are
objects as well and having state as well.

> At least that's how I understand things in the Smalltalk way of defining
> classes and instantiating objects.

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

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




-- 
Best regards,
Igor Stasenko AKA sig.