On Sep 3, 2008, at 9:42 PM, itsme213 wrote:

> I have some Squeak code that I want to try out in Gemstone. My  
> squeak code
> uses traits, Gemstone does not support traits. Since (a) I am not  
> doing
> fancy trait stuff, and (b) I want to keep a trait-like separation in  
> my
> code, and (c) I want to use Monticello to ferry between squeak and  
> gemstone,
> I was going to:
>
>  - replace each trait with a corresponding class
>  - simply copy all trait methods to appropriate classes when needed
>  - put a "TRAIT METHOD - DON'T EDIT" comment in the methods :-)
>
> Any glaring problems in the approach below?
> Better solutions?
> How do I control which method-category these are copied into?
>
> Class>> allMethodsUpto: aSuperClass injectInto: traitUser
>  self methodDictionary keysAndValuesDo:
>    [ :k :v | traitUser addSelector: k withMethod:  v ].
>  (self superclass ~= aSuperClass) ifTrue:
>    [ self superclass allMethodsUpto: aSuperClass injectInto:  
> traitUser ]
>
> ... elsewhere I know which (normal) class uses which (trait) class:
> (self classesUsingTrait: trait) do: [ :traitUser |
>    trait allMethodsUpto: Object injectInto: traitUser ].
>
>
> Many thanks - Sophie
>
> p.s. It would be great if there was a more portable implementation of
> trait-like functionality.

:)

We are working on a couple of fixes for traits (to avoid the sharing  
of compiledMethod which
retrospectively was just a nice hack but introducing more problems).
Next we will fix the class reflective api (we have a nice one with  
trait queries).
Next we will fix some of the bugs
Next we will fix MC problems so do not hesitate to report bugs.
We want to use Nile in Pharo
and we want to start building a new collection hierarchy.
Adrian got a goodies to flatten traits but I do not know it.

Stef
>
>
>
>
>
>