<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br><div><div>On 20 Feb 2008, at 11:47, stephane ducasse wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Monaco" size="2" style="font: 10.0px Monaco">Yes it is clearer. Now traits got aliasing but not renaming because it was simpler :)</font></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 10.0px Monaco; min-height: 14.0px"><br></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Monaco" size="2" style="font: 10.0px Monaco">Stef</font></p> </blockquote></div><br><div>Simpler was a large part of it. We did consider renaming, and looked at the renaming facility in Eiffel. "Simpler" does not just mean "simpler to implement"; the flattening property, which gives a nice simple semantics to traits, would go if we added renaming. The claim that you can understand trait code without understanding traits would also go.</div><div><br class="webkit-block-placeholder"></div><div>We made a judgement call that by not having renaming, and instead only "one sided" aliasing, the loss in utility would be outweighed by the gain in simplicity. On the one hand, even if we were right then, we may no longer be right now: given that traits have succeeded, and that more people are now familiar with traits, the additional complexity may be easier to justify. On the other hand, we may have been right then, and may still be right now.</div><div><br class="webkit-block-placeholder"></div><div>There are alternative ways of solving the problem in itsme213's original post. One would be to give traits private instance variables. Then the trait TCollectionInstVar would be included twice, aliasing the exported methods in both cases, to addCar, addHouse, etc. The name of the instVar itself would be private to the trait, and inaccessible from the class — this could be implemented by using a genSym for the insVar. We still loose the flattening property, at least in its simplest form, but the idea of trait-private inst vars is simpler to understand, I think, than deep renaming, and is useful for a lot of applications. Two applications that we thought of in 2002 were a trait that adds locking and a trait that adds transactions to an existing class. The traits would need a place to put the lock or to put the Transaction id, and it seems much more elegant to make that place private to the trait.</div><div><br class="webkit-block-placeholder"></div><div>Of course, it is also possible to solve itsme213's problem with traits as they stand, by making the name of the instVar a parameter to the trait methods, and using instVarNamed etc. to access it. Or, just duplicating the code. We have been duplicating code like this for 25+ years; it's part of the penalty that you pay for having such a tiny language as Smalltalk.</div><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Andrew</div><div> </div></body></html>