Larry, chromatic, Allison, Damian, et al: What's the big fascination with traits?
I read the paper, and at the end where they talked about refactoring the Smalltalk class library, they managed to claim 12% fewer lines of code: > In total, these classes use 46 different traits and implement 509 methods, > whereof 36 are automatically generated accessor methods. This is just over > 5% fewer methods than in the original implementation. In addition, the code > for the trait implementation is 12% smaller than the original. However, the authors continue to report: > This is especially remarkable because 10% of the methods in the original > implementation are implemented �too high� in the hierarchy specifically to > enable code sharing. With inheritance, the penalty for this is the repeated > need to cancel inherited behaviour (using methods that cause a runtime > error) in subclasses where they do not make sense. In the trait > implementation, there is no need to resort to this tactic. Which I interpret as meaning that the "artificially high" code-sharing implementations have caused extra lines of code in lower level classes. So the "12%" figure is inclusive of deliberate pessimization that has been done to substitute clarity for compactness -- presumably "native" code that hasn't been evolved so much would have more compactness, less redundant code, and would yield less than 12% improvement by refactoring into the traits model. So on the grand balance of utility, what are the metrics that traits are supposed to help improve? The 10% reduction of LOC reminds me of the old Assembler rule of thumb: do it last, you'll get 10% faster. Presumably there are some other metrics being improved. Can one or more of you explain what the perceived improvements, and what's the order of significance? That is, give us a 1. 2. 3. list? Thanks, =Austin
