Traits approaching mainstream Squeak

Nick Brown maillist at bredon-gill.demon.co.uk
Wed Aug 31 16:47:09 UTC 2005


All,

Thanks to everyone who has replied. When I heard the use of traits in 
collections described first as a toy, then as a bad example, I had 
started to think I might have got the wrong end of the stick.

Martin Wirblat wrote:

> 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.
>
Agreed, although I do find it interesting to wonder how much of that is 
because it's awkward to do at the moment.

> - 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 ;)
>
I was assuming (1), in the sense that I'd like to think we could 
ultimately achieve that.

> 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.
>
[SNIP]

>
> 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.
>
Performance in Squeak is important, but is there a general performance 
problem with Squeak, or do newcomers get turned off because one of the 
first things they get exposed to is Morphic, which can in many ways feel 
slow? If I make a list of areas of Squeak where I've found a performance 
problem (other than Morphic), off the top of my head, I get: hashing in 
large collections, CrLfFileStream; that's about it.

I have no idea how much of a general performance impact there could be 
by forcing so much state access through accessors, nor how much of it 
could be regained by various means (I seem to recall somebody suggests 
that the accessors could be inlined, but can't find the message now). My 
feeling is that I would not worry very much about a performance problem 
caused by traits until I can see it.

Regards,
Nick






More information about the Squeak-dev mailing list