Hi!

[SNIP]
>> Wanting code to be concise is code smell?  If you meant adding a method
>> to collections that only joins strings is a code smell then ok, but
>> otherwise.... well I strongly disagree to say the least.
>
> Concise can mean different things. If it means a bloated collection
> interface to accommodate every single person's pet extensions then I
> think that stinks. And that's exactly what we've seen over the last
> years - ever-increasing amounts of partially overlapping functionality
> none of which is widely used and only makes it more difficult to find
> the few truly useful methods. Split for example, is for all practical
> purposes completely subsumed by findTokens: so why do we need split in
> addition to findTokens?
>
> Cheers,
>    - Andreas

I agree with Andreas here and my only comment is that renaming methods
(and using deprecation procedures of course) to a better name is on the
other hand a good thing to do - my guess is that people often don't find
findTokens: because neither of the two words "find" and "tokens" are
likely to be used when searching in method finder for example.

When it comes to "holy cows" like Collection for example there are a
multitude of aspects to consider:

- Backwards compatibility, worth breaking?
- Deprecation procedure, easy to cope with if we indeed change something?
New names likely to be found etc?
- ANSI and/or similarity with other Smalltalks, worth "doing as the
others" or worth doing it differently?
- Minimalism vs usefulness, keeping the standard protocols small but
powerful and not adding methods that are very seldom used (they can be
kept in extension packages).
- Quality. Changes in these classes need to be rock solid. And yes, if
they don't even have method comments then sorry, I would reject them on
that basis ALONE, because then the author surely hasn't tested or thought
it through enough if he can't bother to even write some small comments.

And while on the subject I still think #removeAll (my own pet Collection
addition that got shot down by some people a few years back) would be
useful :)

And finally - we probably do need a Collection hierarchy
overhaul/cleanup/improvement - but that should be a careful project. I am
not even convinced yet that Traits is a "really useful good thing" (given
discussions I have followed - no personal experience yet though) - I was
as enthusiastic as everyone when Nathanael first did his presentation at
OOPSLA a few years beack - but I (as I presume Andreas too) also would
like to see some solid concincing use of them.

They sound nice in theory, but so does a lot of things. In my experience I
am more and more favouring simpler solutions to problems that involve
fewer components and relations - even if they do indeed break a few
"golden rules" of OO or programming in general (like for example avoiding
redundancy like the plague or not allowing a sinle line of UI code into
domain objects etc).

Oops, this post turned longer than planned - sorry.

regards, Göran