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