Traits approaching mainstream Squeak

Martin Wirblat sql.mawi at t-link.de
Wed Aug 31 10:25:37 UTC 2005


Nick Brown wrote:
> If I feel the need to start creating new classes to represent some of 
> this data, I'm usually just interested in implementing the bare bones to 
> get it functioning. Sometimes I then realize that I'd like my newly 
> created objects to be collection-like or stream-like. Subclassing 
> straight off one of the collection classes isn't the right thing, as it 
> brings with it instance variables to hold the collection's state - I 
> already have the state, what I want is to easily add collection-like 
> behaviour. Richard O'Keefe's enumeration adapter change set from a few 
> years back can be a big help, but it's only a partion solution. In some 
> cases I just end up duplicating as much of the collection protocol as I 
> need.
> 

Interesting example. Here are some thoughts:

- It is probably a rare case to have something collection-like but being 
not a Collection i.e. having state in a way that direct subclassing of a 
Collection can't be used.

- In order to use Traits to make such an object behave like a Collection 
I guess that either

1) the Collection hierarchy must be heavily traitified out of the box or 
2) one would have to change it that way at a particular spot or
3) one would have to duplicate some Collection methods to traits ;)

The first version looks to me like being really slow. Wouldn't it mean 
that almost or absolutely _no_ access of state is done directly in the 
standard classes other than in the accessors? That would surely be 
unacceptable slow.

And the second may not be the right general style of working other than 
for temporary experiments. I mean changing the Collection hierarchy 
implies checking every new Squeak version if the "private" Collections 
do still the same as the official ones.

Overall I have to restate here, what I tried to express some times now. 
One method of business is the analysis of weak points. Often it is much 
more rewarding to find and eliminate the weak points than to concentrate 
on building out strengthes. Squeak has weak points and one of it is the 
suboptimal speed. Working with it is often unpleasant UI-wise and of 
course there are applications that suffer from low speed.

But have you all ever thought how many programmers did not switch to 
Squeak, because they conducted benchmarks in their early evaluation of 
it, causing them to immediately drop the mouse like a hot potato?

So my feeling is really that speed is much more a weak point than any 
shortcomings of Smalltalk's single inheritance.

Regards,
Martin



More information about the Squeak-dev mailing list