Classes as Packages (was: Harvesting infrastructure)
Anthony Hannan
ajh18 at cornell.edu
Mon Nov 18 21:53:48 UTC 2002
Sorry Todd, I forgot to address your question before. Here it is:
tblanchard at mac.com wrote:
> I think inheritance is way overworked as a composition mechanism.
> There are other more interesting techniques that have been
> underutilized including delegation and forwarding and method
> categories. I do more ObjectiveC than ST and ObjC has method
> categories - loadable groups of methods that you can add to a class
> anytime you like without recompiling. This lets you add behavior to a
> class without really changing its type. (Inheritance generally
> indicates type - which is different from protocol).
> Your MI approach sounds something like categories - but adds fuzzy
> typing ideas too I think.
> Maybe I don't entirely understand your proposal - but suppose a package
> requires the addition of a bit of behavior to Object - will Object now
> derive from something else too?
Yes, you would add the behavior required by the package in a new
behavior and make Object a subclass of it. Or if you think it is
general enough to Object, you would create a new version of Object and
add your methods to it directly. Putting it in a new behavior implies
that it is not really general to Object and may even be used someday
independently of Object. Object is a bad example of this because it is
the super of everything, so imagine extending some class A by adding a
superclass to it called behavior B. Senders of behavior B will assume
the receiver to be an instance of class A. But that may change, some
other class C may decide to be polymorphic with class A with respect to
behavior B. Class C could then inherit from behavior B directly and
override just what is necessary. In single inheritance, class C would
have to reimplement all methods of behavior B even if a lot of them were
the same.
Cheers,
Anthony
More information about the Squeak-dev
mailing list
|