On 20 Feb 2008, at 11:47, stephane ducasse wrote:

> Yes it is clearer. Now traits got aliasing but not renaming because  
> it was simpler :)
>
> Stef

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.

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.

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.

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.

	Andrew
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080220/e532166d/attachment.htm