[squeak-dev] Traits (was Re: Universal Composition and modules)
siguctua at gmail.com
Thu Dec 3 19:39:08 UTC 2009
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.
> 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
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
> 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 :)
Igor Stasenko AKA sig.
More information about the Squeak-dev