A Traits question

> Where the intent is roughly equivalent to some intermediate traits:
> TraitA>>a
>  self x
> TraitA>>b
>  self y
>
> Trait named: #TraitA1 uses: { TraitA }
> TraitA1>>a1
>  self x1
>
> Trait named: #TraitA2 uses: { TraitA }
> TraitA2>>a2
>  self x2

> "itsme213" <[hidden email]> wrote
>
>
>  > Where the intent is roughly equivalent to some intermediate traits:
>  > TraitA>>a
>  >  self x
>  > TraitA>>b
>  >  self y
>  >
>  > Trait named: #TraitA1 uses: { TraitA }
>  > TraitA1>>a1
>  >  self x1
>  >
>  > Trait named: #TraitA2 uses: { TraitA }
>  > TraitA2>>a2
>  >  self x2
>
>  I left out...
>  Object subclass: #MyClass
>   uses:  { TraitA1. TraitA2 }
>
>  - Sophie
>
>
>
>
>

> "itsme213" <[hidden email]> 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
>
>
>
>
>

>
> 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.