Klaus D. Witzel wrote:
> Have a look at the current effort for the 3.9 release, perhaps after 
> looking at
> 
> - http://www.iam.unibe.ch/~scg/Research/Traits/
> 
> to find out if no one really knows how to modularize Squeak.

Interesting. Can you elaborate on how you think traits deal with/help 
modularization? I would actually (from my current point of view which is 
based on the available examples) claim the opposite - traits being a 
tool for "more reuse" seem to make relationships between classes and 
their (compositions of) traits even more intricate than before. At least 
that's the feeling I get when I look at their current use for defining 
the metaclass hierarchy (if anyone has a better real-world example I'd 
be interested in studying it; but please no toy examples ;-)

The relations between the fifteen or so traits that ultimately make up a 
class seem to be fairly elaborate and (in my eyes) much more fragile 
than I would have expected. To give an example, have a look at 
TBasicCategorisingDescription (which I chose at random, the same applies 
pretty much to all of these traits) - even by roughly glancing over the 
trait I find several methods that are implemented nowhere in sight but 
that have very specific requirements (#organization, #organization:, 
#includesSelector:, #isClassSide, #classSide) which strikes me as very 
unmodular indeed. It seems in particular problematic that there is no 
information which of these selectors are actual (computational) 
requirements, which ones are (assumed to be) state and which ones are 
simply bugs (by elimination). There is zero information about the 
interface of these requirements (arguments taken, return values, error 
conditions), whether the methods are assumed to come from a common 
(required) trait or whether it's just a loose collection of random 
methods (like, for example, a utility trait for implementing unrelated 
math functions). All of which I think are critical if you want to build 
a modular system (and btw, much of that information *is* readily 
available as soon as a trait is used in a functioning class but that's 
exactly the point here - traits themselves definitely loose some 
modularity when they try to stand on their own -modular- feet).

So to me it really does feel as if, yes, reuse is being maximized, but 
modularity is actually being sacrificed in that process. Also, remember 
that duplication of code is not necessarily a bad thing if one tries to 
minimize dependencies which is typically a good idea for modularity. 
Contrary to which one of the primary goals of traits is to maximize 
reuse and minimize duplication which makes the goals at least somewhat 
incompatible. And although one could argue that the expected gains of 
traits offset the loss of decoupling I get the distinct feeling this is 
not true for the examples we currently have - if I would want to reuse 
any of these traits I really wouldn't know how (other than in precisely 
the same form they're already being used in). That, I think, was the 
most surprising result when looking at actual code but it may partly be 
related to tools issues (although I doubt that because no tool will tell 
you what a non-existent method's expected return value is if you load a 
trait and have no existing composition at hand to look at).

Now it may be that this is not a good example but it's the only 
real-world traits use that I've seen so far (toy examples discounted). 
Anyway, if you think that example is badly chosen or if you have another 
example that shows how traits help modularity (or even if you just have 
gut feelings ;-) I'd be interested in hearing more about it.

Cheers,
   - Andreas