On 8/30/05, Martin Wirblat <sql.mawi at t-link.de> wrote:

> - the Collection hierarchy works and there is no practical problem with
> its daily use.

Generally, this is true. But this hierarchy has some flaws which
traits can improve. For example, by reducing duplicated code,
maintenance is greatly simplified.

> The dominance of philosophical problems with regard to Collections 
> shows IMO that there is indeed no real problem with them.

The dominance of philosophical problems I find with regard to your
reasoning shows that there is no real problem with your reasoning. :-)

> Generally everything
> within the Collection hierarchy is _very_ easy to understand.

Yes; I believe that this is one key reason why it was chosen for the
research paper. Because Collection relies upon very straightforward
analogies to real-world objects, the code is quite simple, for the
most part. One would not expect that such code would benefit much from
traitwise refactoring, so the work done in the paper is all the more
impressive.

> - and there is no problem with the implementation of it, in the
> practical sense that a rare occurring bug is - once found - easily resolved.

Yes and no. When code is duplicated, who ensures that a bug found in
one place is corrected in every place?

> All that makes Collections a really unconvincing example of what to gain
> from Traits. So for the Collection hierarchy it seems to boil down to a
> deal between space vs speed. You save space, but you lose speed.

What loss of speed are you talking about? Is it the overhead of using
access methods rather than directly using instance variables, or is
there something else?

It seems that the developers' hope here is that whatever speed is lost
due to using traits will be offset by cleaner code available sooner,
in every part of Squeak.

> - Such a deal alone should not be the reason for a language extension or
> change. Especially not for a really good and proven language like Smalltalk.

Ah, here I think we have the most important objection. It's not
Smalltalk if it's got traits. You're right, there. This isn't a small
change like adding color to BitBlt, or letting curly braces make an
array. It's making the structure of the language different in a
fundamental way.

Smalltalk is proven by years of use. Let us not take that fact to mean
that it cannot be improved upon. Let us also not make changes without
due care.

I am skeptical. I'm willing to be shown that traits are a good idea,
and I'm willing to be shown that they aren't. I'm willing to take the
chance because it's nothing we can't pull out of Squeak if we don't
like it. (Or redo if we want it done differently, for that matter. I'm
looking forward to the day when somebody makes traits that can
directly access instance variables.)

At the moment, the main efficency that traits seem to provide is
_human_ efficiency, in that a human being has to spend less time (we
hope) reading, writing, debugging, and maintaining code. This is a
Good Thing.

In the end, we may not want a heavily-used class hierarchy such as
Collection to be implemented with traits. But we won't know for sure
what traits are good for, until we've given traits a try.

--Tom Phoenix