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

Stef

On Feb 20, 2008, at 5:35 PM, itsme213 wrote:

> "itsme213" <itsme213 at hotmail.com> wrote
>> Say I have a trait which manipulates a collection inst-var: ....
>
> I had the #x->#y backwards in my last post. Below is the full example,
> cleaned up and better named:
>
> Say I have a trait which manipulates a collection inst-var:
>
> Trait named #TCollectionInstVar
>>> addToInstVar: x
>            self iVar add: x
>>> removeFromInstVar: x
>            self iVar remove: x
>>> doOverInstVar: aBlock
>            self iVar do: aBlock
>
> I have a class which could use this trait on two of its instance- 
> variables:
>
> Object subclass: Person
>   instanceVariableNames: 'cars houses'
> Person>>cars
>   ^ cars ifNil: [cars := OrderedCollection new]
> Person>>houses
>   ^ houses ifNil: [houses := OrderedCollection new]
>
> I want to use TCollectionInstVar on my Person class, twice, on #cars  
> and
> #houses. I need to rename both provided & required methods to do this:
>  TCollectionInstVar @ {
>    #addCar: -> #addToInstVar: .
>    #removeCar: -> #removeFromInstVar: .
>    #doCars: -> #doOverInstVar: }
>   requiring: { #iVar -> #cars } "change 'self iVar' to 'self cars'"
> and
>  TCollectionInstVar @ {
>    #addHouse: -> #addToInstVar:
>    #removeHouse: -> #removeFromInstVar.
>    #doHouses: -> #doOverInstVar: }
>   requiring: { #iVar -> #houses } "change 'self iVar' to 'self  
> houses'"
>
> This would be equivalent to using two (anonymous, auto-generated)  
> traits
> which are derived from TCollectionInstVar, which rename the required  
> method
> from #iVar to #cars and #houses, respectively (i.e. any send of  
> "self iVar"
> is rewritten to a "self cars" or "self houses").
>
> Since many behaviors of an object are focused on just some part of  
> its state
> (wrapped by accessors), I find many places where I want to  
> parameterize a
> trait by the "required method" it will use to "call-back" to my class.
> Having this "call-back" hard-coded in the trait with no way to  
> override
> makes that trait much less re-usable.
>
> As Andreas pointed out, this would be solved with proper "renaming" of
> methods (both provided and required, probably written #old->#new, not
> #new->#old) when using traits, as opposed to the current "aliasing".
>
> Hope I was clearer that time, and please tell me if I should be  
> thinking
> differently about this.
>
> Thanks - Sophie
>
>
>
>
>