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
|