[squeak-dev] Traits (was Re: Universal Composition and modules)

Ronald Spengler ron.spengler at gmail.com
Thu Dec 3 20:21:32 UTC 2009

Igor: +1. I think the technical plane is in part a function of the
social plane. What Traits needs more than anything else is more
documentation. Research papers are great, but some tutorials would be
useful to newbies like me.

FYI the paper in question mentioning the collections refactoring is here:


And the rest of the documentation is here:


On Thu, Dec 3, 2009 at 11:39 AM, Igor Stasenko <siguctua at gmail.com> wrote:
> 2009/12/3 Eliot Miranda <eliot.miranda at gmail.com>:
>> 2009/12/3 Stéphane Rollandin <lecteur at zogotounga.net>
>>>> What problem are you trying to solve?
>>> well, I have several issues that would be nicely addressed by Traits. the
>>> problem I would like to see solved is that of usability of Traits in Squeak.
>>> I believe Traits are currently not really usable, by lack of system support
>>> (tools, etc.)
>>>> For whatever reason, nobody seems to care enough about this to do the
>>>> tools integration work.
>>> I guess the reason is that the Traits implementors have moved to another
>>> project, where they may or may not have better tool support in the near or
>>> far future.
>>>> It is hard to imagine that adding a different
>>>> (and probably incompatible) implementation of traits would cause the
>>>> tools integration to happen any faster.
>>> I'm not talking about adding an incompatible implementation, I just
>>> recalled that Andreas once said here that the current implementation is
>>> deeply flawed, overly complicated and could be *replaced* by a much better
>>> one. I may be wrong here, which is why I asked.
>>> Stef
>> One issue with the current traits implementation is the cost/benefit ratio.
>>  Because it isn't used except in its own implementation it doesn't pay its
>> way.  It introduces lots of complexity and doesn't return functionality
>> because it isn't used in the places where it could be.  The most important
>> place is the collection hierarchy where a trait-based implementation should
>> in theory produce a much more flexible composable library.  See Bill
>> Cook's "Interfaces and specifications for the
>> Smalltalk-80 collection classes.", from "OOPSLA ’92,".  I'm ignorant of the
>> history but I've also read Andrew, Nathanael and Stéphane's "Applying Traits
>> to the Smalltalk Collection Classes" so I don't know why we ended up with
>> just traits applied to the traits implementation and lost traits applied to
>> the collection hierarchy.  I'd like to know why.  My gut is that it might
>> have broken too much older stuff.  If this is right then IMO this is another
>> strong argument for producing small kernels that can load modules.  One
>> could imagine a kernel that included traits applied to the collections into
>> which one could load packages.  The traits collections kernel and the old
>> collections kernel could exist side-by-side and we could compare, provide
>> migration tools for subclasses of old collections, etc.
> I agree that currently Traits is not widely adopted and used among
> developers (be it Collections or something else).
> I seen couple of times, people saying that it would be cool to use
> traits for rewriting the Collections classes, but to my knowledge,
> nobody started with it yet.
> But i don't agree that there is a bad cost/benefit ratio. I think that
> problem lies more in social plane (widely adopting & accepting new
> idea(s)) and only then in technical plane - i.e. maturity level (both
> implementation and tools).
> I think that traits has many things to offer to developers, in
> addition to smalltalk 'standard' as we know it.
>> Another issue with traits is instance variable access.  Newspeak throws away
>> direct inst var access and only uses accessors so its mixins can add
>> instance variables.  So in some sense the Squeak traits implementation isn't
>> radical enough.  But throwing away inst var accessors really feels like a
>> new language, or at least a new system, because it impacts so many things:
>> at the implementation level the ClassBuilder can and should behave
>> differently, the bytecode set should be different, a JIT should use
>> copy-down, etc; at the class library level one can factor things very
>> differently.
> There are some quite radical ideas concerning traits, which definitely
> will feel like a new language:
> - with introduction of stateful traits, one could completely eliminate
> the class inheritance,
> by replacing it with trait composition.
>> To grapple with the kind of language evolution implied by traits and
>> Newspeak I think we should be working on package-level refactoring that aims
>> at being able to move packages between different languages.  It would be
>> great to back-port Vassili's native GUI from Newspeak.  It would be great to
>> migrate  Andrew, Nathanael and Stéphane's collection classes to Newspeak (or
>> as the Newspeak team is trying to migrate Strongtalk's collection classes).
>>  But doing this manually is IMO insane because its labour-intensive and
>> error-prone.  Yes, parts of any migration may require intervention in the
>> form of hand-crafted rules for special cases but it can't be a first-order
>> process.
>> best,
>> speaking in ignorance of Squeak's recent evolution,
> ignorance is a blessing to learn something new, or a curse, if one
> don't wants to learn :)
>> Eliot
> --
> Best regards,
> Igor Stasenko AKA sig.


More information about the Squeak-dev mailing list