On Mon, 12 May 2008 23:12:45 +0200, Andreas Raab wrote:

> Klaus D. Witzel wrote:
>> It is perhaps possible to go one step further (or go back, for that  
>> matter) and have no instance traits and no class traits, but just  
>> traits (subclass of ClassDescription, instVar 'users'). It can be  
>> applied to either side of some class, since the whole machinery has no  
>> requirement other than #traitComposition (as far as I've seen).  
>> Wouldn't that make the exercise less complex and more clear, or am I  
>> missing something.
>
>  From my POV that's even better but also a little more drastic ;-)

Hhm, all the class traits that I've seen so far tell me this:

- don't even *think* about applying me to any other class than "mine"
- I am *not* reusable, my methods should be ordinary class methods

Class methods carry the burden of instance creation and class  
initialization. Now if such a class traits could *really* be applied,  
*as*is*, say to 100+ potential users, then something must be wrong in the  
realm of the king of Denmark. I mean to say, that for the class hierarchy  
that someone is going to create with such class traits, *something*must*  
be wrong, be it design, inheritance, or whatever.

The traits in category Nile-Base-Traits of Nil-Base-dc.57.mcz, for  
example, have *zero* class traits, for good reason.

The traits in category Traits-Kernel-Traits, for another example, have  
*zero* class traits, for good reason. And all other class traits in the  
Traits-* category are *unapplicable* when not used by the sole class for  
which they have been designed. Re-use? I fail to see any re-use potential  
for the class traits of this package.

People correct me please since there must be something wrong.

But if not, or almost not, then I kindly ask that we do not base our  
decisions on un-reusable cases.

/Klaus

> Cheers,
>    - Andreas
[...]