Hi Andreas et. Al,

Note that we (I think I speak for the other authors as well, if not  
they will without any doubt speak up) do not claim that traits are  
"modules" -- that term is very overloaded anyway, but it typically  
assumes some kind of 'black-box'-ness (strong encapsulation) that  
Traits do not satisfy. When you see Traits as black-box modules you  
get the problems Andreas mentions in his mail (with which I agree up  
until a certain point).

But Traits are more of a white-box reuse model: fine-grained  
composition of groups of methods, as you would do with inheritance,  
but with composition operators. Required methods in that respect are  
more like abstract methods: an implementation has to be given when  
the trait is used in a class. Note that, compared to subclassing,  
trait composition is actually less brittle, since more things are  
checked. And that was the point Traits are trying to solve.

That said, more applications and feedback are absolutely welcome.


On 02 May 2006, at 15:23, Klaus D. Witzel wrote:

> Hi Andreas,
>
> on Tue, 02 May 2006 11:28:49 +0200, you <andreas.raab at gmx.de> wrote:
>
>> 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?
>
> Sure. And apologies in advance if this becomes too theoretical.  
> O.K. base things first, from wikipedia:
>
> "A module can be defined variously, but generally must be a  
> component of a larger system, and operate within that system  
> independently from the operations of the other components."
>
> The emphasis, IMO, is on "...operate within that system  
> independently from the operations of the other components".
>
> Every Traits is such a module, also the composition of two or more  
> Traits qualifies (IMO without any doubt).
>
> I use a simple judgement to see if something qualifies for being a  
> module, a raw translation from the work of
> - http://scholar.google.com/scholar?q=Anne+Berry+separator
>
> a) there are at least two modules in any non-monolitic system which  
> deserves to be called "modular"
> b) there are pairs of modules which are independent from the  
> operations of each other
> c) if a) and b) then there is/are one or more things (the users of  
> modules) which separate pairs of modules
>
>> 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.
>
> This is quite possible and I agree that the example of traitified  
> Traits (TBasicCategorisingDescription et al) can be seen this way.
>
> But I think that at this stage of the Traits story we do not have a  
> convincing view on the relationships between Traits and users of  
> Traits (and between Traits themselves). We just use GOFBrowser as  
> before but what is needed (IMO) is a shift in the paradigm of "...a  
> query path into the class descriptions, the software of the  
> system...". Not that I have a concrete idea on how such a thing  
> would look like, but without any doubt I'd recognize it if someone  
> showed it to me (no, it won't look like http://www.eclipse.org/ ;)
>
>> 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.
>
> This is, again in my eyes, a direct consequence of the  
> modularization effort of the author of these requirements: it tells  
> me that the author didn't want to know anything about how a  
> Behavior decides #includesSelector: and how a Behavior manages  
> #isClassSide and #classSide, and that {#organization.  
> #organization:} are just getters/setters.
>
>> 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).
>
> Out of curiosity, why do you want to know which ones are state?
>
>> 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).
>
> Don't get me wrong but isn't this the case for *most* methods in  
> Squeak? If you can agree then we can put this issue aside (until  
> "somebody" fixed the documentation problem, I mean ;)
>
>> 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).
>
> I agree, this (your comment) comes close to my a)-c) view from  
> above, in the sense that modules are "nothing" in the absence of  
> their user(s).
>
>> So to me it really does feel as if, yes, reuse is being maximized,  
>> but modularity is actually being sacrificed in that process.
>
> Well, my impression is quite the opposite: only because the author  
> *did* this (IMO high) level of modularization, he/she was able to  
> lay the ground for maximizing reuse of this particular Traits. Of  
> course if there is only *one* user, then... But I also think the  
> author has given Traits traits as a high level example on how to do  
> "it".
>
>> 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.
>
> This is the point at which I view users a separators: have a look  
> at the average non-traitified classes and how they are used: the  
> more "glue" code a user needs, the less the value of  
> modularization. Take for example Http-readable content, to be  
> paired with CrLf conventions: no way unless one accepts to read the  
> entire contents, before being able to apply CrLf conventions by  
> using an *existing* module (this is just an example, no one take  
> this personal, please).
>
>> 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).
>
> Agreed, this amounts (again) to a shift in the GOFBrowser paradigm.
>
>> 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).
>
> I'd say the example you used is a good one. It is fairly complex  
> and is part of something which everybody in squeak-dev understands:  
> behavior.
>
>> 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.
>
> I hope it was possible to demonstrate my view on modularity and  
> Traits.
>
> /Klaus
>
>