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