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
|