Michael Rueger wrote:
> Glad this discussion came up.
> Just to be clear, I'm all for having the Traits kernel in 3.9!
Well, I'm glad to hear it. And I hope you'll help us get it in, and get 
it right.

> But, at first I would suggest, and I think you want to do this anyways, 
> that traits are not actually used. Not because they don't work or 
> anything, but because of design considerations. So my gut feeling is 
> that we should not use it for major refactoring of the system core in 
> the near future.

Well, first of all, I understand your caution. I'd say its even quite 
worse, they'll probably even "not work" in some ways, at least until 
we've used them for a while and flushed the bugs. Just the other day, 
Marcus and I found by accident that Traits break the current 
implementation of CompiledMethod>>who, because a traits CompiledMethods 
are shared with the classes that use it. So at the moment, #who might 
respond with some using class, instead of with the correct defining trait.

> OOP has taken many years to come up with something like patterns and my 
> guess is that, although not quite that long, it will take some time for 
> best practices to emerge for traits.
For better or for worse, I think the same effect as above applies also 
to the design aspect you mention now, and Andreas was asking sharp 
questions about before - we won't know how to use them until we've done 
it for a while.

Anyway, I hate to say it, but your proposal is hard to follow. The 
problem is that Traits share lots of responsibilities with Classes. So 
we need to either share or duplicate a lot of code. Sharing 
implementation by inheritance in this case seems impractical because 
Classes already have a complicated hierarchy. Sharing implementation by 
delegation as Andreas suggested for a specific responsibility would 
still require duplicating the delegation (or DNU tricks) and carries its 
own costs. The remaining alternative I see (not that this was my idea) 
is to use traits to solve the problem. Maybe you have a specific idea on 
how to avoid using Traits, and avoid duplication that I didn't come up with?

> Please don't get me wrong, I'm not trying to be negative here, just 
> cautious and wouldn't mind if you prove me wrong ;-)
Well, I can't say I can prove you wrong. But I get the impression that 
Traits happen to be a pretty good solution to the problem at hand in 
this case (and I'm not only saying this because it would be hard and 
work intensive to do it over in a different way).

> Somewhat related:
> how do traits affect packages? Should/can they be in separate packages?
There are two general ways to package code that uses traits:
1. With the traits flattened. Each method appears in each class that 
gets it from a trait. This means that lots of code is duplicated and 
shown under a different place from where it is actually defined. The 
traits don't explicitly exist, and the code is valid smalltalk.
2. Traits enabled. Each trait appears in some package, just like a class 
would. For every class and trait, their declaration includes the 
information of what traits they use. Each method appears only in the 
class/trait in which it is actually defined. This is how I think things 
should be eventually. Just to be clear, in this case a trait can be 
packaged separately from the classes that use it, just like a class can 
be package separately from its subclasses.

At the moment only 2 is implemented, but 1 is required for backwards 
compatibility with older versions of Squeak and the rest of the 
Smalltalk world.

BTW, maybe we should create a Traits project in mantis to keep track of 
all of the proposals made...

Daniel