Traits for modularity (was: Re: Peeping At The KeyHole)

Klaus D. Witzel klaus.witzel at
Tue May 2 13:23:16 UTC 2006

Hi Andreas,

on Tue, 02 May 2006 11:28:49 +0200, you <andreas.raab at> wrote:

> Klaus D. Witzel wrote:
>> Have a look at the current effort for the 3.9 release, perhaps after  
>> looking at
>>  -
>>  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

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 ;)

> 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.


More information about the Squeak-dev mailing list