On Saturday 26 February 2005 4:57 am, Martin Wirblat wrote:
> I assume that you mean this other structure is or could be built of
> ordinary Smalltalk 

Yes, though Traits *is* "ordinary Smalltalk". That is, it's more of a 
code-management and code-analysis scheme than anything else. If you look at 
the definition of a class that uses Traits in an ordinary browser, you can't 
tell that Traits is being used. You have the same method dictionary, instance 
variables, etc.

It's just that Traits lets you see and manage the behavioral requirements and 
related code responsibilities of your classes better.

But instead of copying methods from one class to another with related 
behavior, Traits lets you have a single copy of the source of the related 
methods. And it lets you talk about these groups of methods and their 
relationship to other such groups and classes.

> and for such cases Traits is used only as a
> "thinking-help" in a two-tiered development process:
>
> 1) Do it with Traits
> 2) At many places, traits are indications that you have done something
> wrong. Do it differently (without using traits).
>
> Interesting, but a bit indirect :) and as I said perhaps people are not
> aware of the second part. Thinking abstractly I am really unsure if this
>    is an argument in favor of Traits, it looks like being able to use a
> trait may put you on the wrong trail.

Perhaps. I do think that the Traits documentation focuses rather heavily on 
"re-engineering" or "refactoring" existing code. While this is certainly 
necessary and helpful, the Traits documentation could stand a better 
description of how it can be used to write new code and then maintain it.

There is nothing you could write in Traits that couldn't be written by copying 
methods between classes. It's just that it's much harder to maintain code 
written in that way. And the automatic analysis and grouping of methods into 
Traits is a powerful adjunct to (or replacement of) method categories.

-- 
Ned Konz
http://bike-nomad.com/squeak/