On 8/30/05, Martin Wirblat sql.mawi@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