Traits for modularity (was: Re: Peeping At The KeyHole)
Andreas Raab
andreas.raab at gmx.de
Tue May 2 09:28:49 UTC 2006
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
More information about the Squeak-dev
mailing list
|