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:
http://scg.unibe.ch/archive/papers/Scha02bTraits.pdf
And the rest of the documentation is here:
http://scg.unibe.ch/research/traits
On Thu, Dec 3, 2009 at 11:39 AM, Igor Stasenko siguctua@gmail.com wrote:
2009/12/3 Eliot Miranda eliot.miranda@gmail.com:
2009/12/3 Stéphane Rollandin lecteur@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.