Classes as Packages (was: Harvesting infrastructure)
tblanchard at mac.com
tblanchard at mac.com
Wed Nov 20 08:44:24 UTC 2002
OK, I sort of like the idea behind the mechanism - but I think its a
distinct mechanism from "inheritance" - as pointed out there are the
issues of how super is bound.
I'm still not comfortable with extensions of Object becoming
superclasses of Object. I think that could introduce some ugly
circularities. Also, since these behaviors are chunks of behavior sans
state - something else has to define the structure of the storage - so
we have two kinds of things now - classes with state and stateless
classes.
If they are two things I think they deserve two unconfusing names.
So I don't object to the mechanism per se - but I don't much like the
terminology. I think it is going to be confusing - especially to users
of more conventional pretend OO languages (the [CJ]++# crowd).
Anyhow, whether its called traits, categories, bundles, or snozwangers,
I'm looking forward to getting the mechanism.
On Wednesday, November 20, 2002, at 02:00 AM, Anthony Hannan wrote:
> Hi Todd,
>
> tblanchard at mac.com wrote:
>>> Yes, you would add the behavior required by the package in a new
>>> behavior and make Object a subclass of it.
>>
>> Why is it a subclass? These "classes" you are describing don't seem
>> have much in common with the classes we have now. For one thing,
>> you've mentioned that there is no state. But Smalltalk classes
>> generally do have state. So are you implying we change classes in
>> Squeak to not have state, or are you saying these mixins you are
>> proposing aren't really classes like we have now but something else?
>> Personally I'd rather have method bundles (categories) that add to a
>> class without requiring mucking about with the class hierarchy.
>
> You may have already figured out by now from my other emails, that I'm
> proposing a single type of behavior object, call it behavior, class,
> trait or whatever. A behavior holds a set of methods and inherits from
> other behaviors. "Inherit" means include methods from other behaviors,
> and can be implemented in the following ways:
> (1) search inherited behaviors during method lookup (our current
> implementation), or
> (2) copy inherited methods into the inheriting method dictionary
> (traits composition), or
> (3) add new method bundles (class extensions), like you suggest.
> All of these are forms of inheritance. 1 and 2 are equivalent except
> the former consumes more time and the latter consumes more space
> (ignoring method cache). 3 is equivalent to inherting the class
> extension and giving it precendence over previously added extensions
> and
> other inherited behaviors (a la CLOS). This ordering is problematic as
> raised in the Traits paper (page 5) and its references. This is also
> why I claim packages should not use this technique.
> So I'm saying inheritance is fudamentally the same so lets implement
> it
> the same throughout the system. I'm further saying all behaviors are
> the same (after you remove instance variables) so lets implement them
> the same as well.
> I'm proposing that we replace instance variables with accessor
> methods,
> so all behaviors are just collections of methods and equally reusable.
> It's like shifting the state responsibility from the behavior to the
> method, which I think is appropriate since even local senders don't
> care
> how a selector is implemented (stored value or method).
> These accessor methods need to check the class of the receiver before
> reading/writing. This is only necessary because we optimize slot
> access
> by translating accessors into indices. If objects were dictionaries
> keyed by accessor than this would not be necessary and the accessors
> would work on sub-instances also. Subclasses could then override an
> accessor if it wants, but with indexed slots they have to (its no big
> deal). So when instantiating a behavior the instance has the same
> number of slots as the number of write accessors in the behavior. Each
> accessor has an assigned slot number.
>
>> As for adding protocol to Object - its done fairly often - simple
>> example is to have a project Foo that manages FooElements - I'm quite
>> likely to add a method category FooExtensions to Object and put an
>> isFooElement method (returning false) that I override in FooElement to
>> return true.
>
> FooExtenstions would be a super behavior of Object, which is equivalent
> to adding its methods directly to Object (see #3 above).
>
> Cheers,
> Anthony
>
More information about the Squeak-dev
mailing list
|