Post by Igor StasenkoPost by Igor StasenkoA 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.
Post by Igor StasenkoOf 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.
Post by Igor StasenkoFrom "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.
<***@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