Martin Wirblat wrote:

> 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.

Why do you say this?  There are ways and means to deal with this - if it 
is actually a significant problem.  Time saved in 
development/maintenance may mitigate this, also. 

>
> 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.

Possibly -- but I do not think Squeak was really ever meant to be a 
production environment -- would be nice to be able to throw a 
(preferences) switch to  'production' :-)

David