To Traits Or Not To Traits
Last updated at 4:32 pm UTC on 14 January 2006
General introduction see To Traits Or Not To Traits (includes link to main project page)
Martin Wirblat 23 Feb 2005 [As part of a larger discussion, wrote;] Traits is a questionable language extension. It is questionable because language extensions to Smalltalk themselves are questionable. What real problem does the language extension/change solve?
Cees de Groot This is indeed the correct question to ask if we want to brace ourselves against flying off into coolness land (which you assume as a given, I as something to be decided upon.) AFAIK, the real problem Traits attempts to solve is about structuring, and it looks like me that when you're putting 'library' high on the list of itches we should scratch, a cleaner structuring of some ugly bits of the base library's hierarchy seems to be one of the things that Traits can contribute. It would probably become a whole lot easier to reuse code from the base library with a Traitified image (I'm talking from memory here - it's been a while since I read the Traits paper so it might be I'm missing other strong points).
But the proof of the pudding is in the eating, I think. When there's a Traits browser, and the stuff is all a loadable package, people can start using it and see whether it solves real-world problems in a way that makes it worthwhile to adopt it as a core piece of Squeak.
The only thing I'm afraid of is that we're adding too much friction to the process of changing Squeak; as some of the original Smalltalk-80 members have complained, the language has become essentially frozen since it left the laboratory. For 25 years, it looks like we've missed out on opportunities to get this whole OO thingy to higher levels, and I wonder whether that's a good thing. I respect these guys a lot, but I don't think that they invented the final computer language 25 years ago.
stéphane ducasse [To understand the value of Traits you need to read the papers]
http://www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf Takes 15 min and explains the Traits model.
http://www.iam.unibe.ch/~scg/cgi-bin/oobib.cgi?query=nathanael+applying+traits+to+the+collection+hierarchy+oopsla is The OOPSLA 2004 papper shows traits at work
http://www.iam.unibe.ch/~scg/Archive/Diploma/Lien04a.pdf is a fun paperon applying traits at the meta level
http://www.iam.unibe.ch/~scg/Archive/Diploma/Lien04a.pdf Adrian on bootstrapping squeak http://www.iam.unibe.ch/~scg/cgi-bin/oobib.cgi?query=a+browser+for+incremental+programming+computer+languagesYou have one on the browser
http://www.iam.unibe.ch/~scg/cgi-bin/oobib.cgi?query=Nathanael+traits+tools+and+methodology the methodology
Steven Swerling Here are a few links:
General Overview: http://www.iam.unibe.ch/%7Escg/Research/Traits/index.html(links to some key papers on traits)
Overview of Squeak Implementation: http://www.iam.unibe.ch/~schaerli/smalltalk/traits/traitsPrototype.htm (includes very helpful screenshots of traits in action)
You look at this stuff and have to wonder of Traits might not be a nice arrow to have in the quiver for modularizing the image.
When to add Traits
Lex Spoon How about waiting until the beginning of a release cycle to make a major change like adding Traits? I assume it is likely to bring out a lot of bugs? If we do it at the beginning of a release cycle, then we can take our time and get the bugs out.
Also, how are the Traits tools, at this point? Are there browser updates, etc., so that people can use them like a normal developer instead of imagining what it will be like in the brave future? (Or acting like an icky files+compilers developer? :))
firstname.lastname@example.org As Cees described in more detail, Traits needs a longer period of digestion IMHO. I mean, when we have a beta of the Traits that is meant to be the Real And True version :) - then we can all play with it and see how it works etc. And then, we can start thinking about including it into the official Basic image.
stéphane ducasse In my opinion, in three weeks from now traits browsers will be ready. besides that all the rest is working. Even when you recompile a method in a debugger you recompile in the right place (traits or classes).
Can we add Traits as a Package
email@example.com But this only works if Traits can be implemented as a package. I still don't know that. Nathanael?
stéphane ducasse Why as a package? I do not understand why you are saying that? Bootstrapping the kernel is not something that you can do in a package. Or you will complain that traits are not integrated you cannot have the butter and the money for the butter.
firstname.lastname@example.org What I mean is that if Traits can not be packaged as a package (if for example it is simply too hard to do) - then our choices are much more black and white. If it can be made a package then people that are die-hard negative about Traits can still elect not to use it. They can then use Minimal (you know - the image smaller than Basic) and simply not install Traits into it.
Now, I understand that maintaining Traits as a package is a hard thing to do. It is typically a quite advanced "patch" to the kernel stuff in Squeak. This all depends on how you guys have built it - through various refactorings or through simply modifications. So the question remains - is Traits plausible to maintain as a package - or is it not? And also of course, if it is - would you be willing? Unless this is so - then this turns into a black and white choice.
Blake I don't think Traits takes away any functionality. If one doesn't want to use them, one doesn't have to. Yeah, they'd be there. But if they give the benefits they seem to, does it make sense to cripple the core to satisfy those who hate them so much they don't want them anywhere in their image? I guess packaging them removes the issue but, yow, that seems like a lot of work (if it's even possible).
stéphane ducasse What I can tell you is that it is possible to have traits as package but this is a sweet dream because each time the kernel will changes then you will have to fix traits. You will not be able to get the full power of traits because you will not be able to rethink to core Collection/Stream/UI using morphic then each time you will load the traits package it will just recompile all your image = 30 min of recompilation. Then do you imagine that nathanael or adrian will work on checking drifts over the years especially since this is really simple once in the image (because traits are simple). So a package = slow death but death.
stéphane ducasse [Responding to a suggestion from Ned that maybe doing some refactorings of Minimal would allow a smoother loading of Traits] The problem is that we are introducing a new hierarchy and changing a bit Behavior so this forces the recompilation of the class hierarchies.
Nathanael Schärli I agree with Stef. While it would be possible to have Traits as a package, I don't think that this is a good idea for several reasons. First, it would mean a lot of care and work to make sure that provide a package that is compatible with newer Squeak releases. More importantly, I think that it kind of defeats the prupose of a langauage extension like traits if it is optional because this means that one cannot take advantage of it in any of the non-optional code.
However, the good news is that even if traits are part of the basic image, people do not have to use and deal with them if they do not want to. So, there really should be no disadvantage/change for people who just want to ignore them. But as I said in my last email, I agree that we should go step by step, and the next step is a beta that allows people to see what it would mean to have traits in the image. I'm sure that this will make things a lot less scary...
Would Traits Be Transparent?
email@example.com This [that Traits shouldn't be a separate package] is what I thought - I just want to hear it spelled out. I would like to hear more about [the idea that you can ignore traits]. Let me take the role of a Traits-hater here:
- Can I use the standard libraries and not know about Traits? Before you say "yes" think it through. For example, if I edit a method in a class that comes from a Trait what happens? Am I editing the Trait? And then I am affecting other classes using it?
- So I am guessing that people do need to know about Traits (if we use them for standard libraries) or else they will get confused. Correct?
- If I don't use Traits and don't use any libraries using Traits (given that no standard libraries use them) and if I... use ordinary browsers etc. What is the effect on me? Does Traits have any effect then at all? Just asking to get a feel for this.
- Does the old tools work if we introduce Traits or do they all break?
- [use the standard libraries and not know about Traits?]Absolutely! The idea is that in the regular browser, changing a method in a class that comes from a trait will define a new method that is local to the class and — according to the semantics of traits — overrides the method coming from the trait. This means that such an edit has the exact same consequences (i.e., it only affects the class and its subclasses) as if the class were built without any traits at all. Similarly, if you remove a method in a class that comes form a trait, the method gets "excluded from the composition" (i.e., it is not removed from the trait but only excluded from this particular application of the trait), which means that it has the expected effect for the programmer who does not know (and does not want to know) that the class is in fact built from traits.
- [do need to know about Traits if used for standard libraries?] No. As I said above, the standard browser hides traits in a completely consistent way. As a consequence, a programmer that does not want to know about traits can use the standad browser, which lets him view and edit any code (even if it is built from dozens of nested traits) in the traditional way without ever accidentally affecting any other classes. This is possible thanks to the beauty of the traits model, which features the flattening property (i.e., methods in traits have no special semantics) and allows the composite entity (in this case the class) to make any kind of local changes (such as modifying or removing methods obtained from a trait) without affecting the traits itself. This is also the reason why traits do not suffer from the fragility problems known from mixins and MI.
- [not using Traits, using ordinary browsers any effect?] If you are using no libraries that use traits, then traits have absolutely no effect on you, except that there are a handful of additional classes in the kernel (such as Trait, TraitDescription, ClassTrait, etc.) that most people are not interested in anyway. However, things are even better because, as I explained above, one major advantage of traits is that they have virtually no effect on people who do not want to know about them even if they use libraries built with traits! The only thing to make this work in practice is to tweak some of the existing tools a bit. We have already done this for the traditional System Browser, which displays the code always as if no traits were used and makes sure that also edits behave exactly as if no traits were used (i.e., changes only affect a class and its subclasses but not other classes using the same traits).
- [the old tools work? ]Because all the work is done at composition time (i.e., the method dictionaries of all classes look exactly as if no traits were used) Most of the old tools (such as "implementors of..." and "senders of..." etc.) work just fine. However, we found that for some of them require minor tweaks to get the perfect illusion of a trait-lest image. What is more work is to design the new tools (such as the trait browser) for the programmers who actually want to know about traits and use them. This is because these tools need to show how classes are built from traits and give the programmer the choice of overriding/removing a trait method in a certain class or actually changing the trait where the method is actually defined. Also, we need to make sure that for those programmers, tools like "implementors of..." and "senders of..." take methods defined in traits into account.
How to save a parts bin There is one effect [of adding Traits]: your image is larger. For those of us wanting to run embedded systems on memory-constrained devices, this can be an issue. How much larger does (the absolutely necessary, hard to load as a package, kernel part of) Traits make an image? I'm assuming that the browsers and other tools could be packaged separately, right?
stéphane ducasse I do not know exactly, but with traits we remove duplicated code since the kernel is bootstrapped. For example, a lot of functionalities are reuse between the new classes and the existing one (classDescription and others). Also collection could gain a be reduced (nathanael showed in the OOPSLA paper 12% of reuse)but without rewriting everything so we could expect a bit more.
[the browsers and other tools could be packaged separately?] Sure.
stéphane ducasse [How might a Traits-based solution look for making the competing frameworks pluggable?] Traits provides you a method categories kind of abstraction with required methods to get the entire method collection working (a bit like an abstract class that you can plug in any class you want).