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