> Oh yes.. I am :) cool
How are you dealing with the fact that the application of trait with state may change the layout of the class user and that you should recompile all the class method to deal with that. And if you have two traits having state you should do the same but for the traits themselves. So this means that the method in the traits cannot be reused (ok now we do not reuse them anymore sniff it was a nice model - reuse without cost of duplication). How your layout object helps you for that? This is why I want first class slot :) Stef > > http://pinocchio.unibe.ch/~tverwaes/slots.tar.gz gives you an image with an > example of a stateful trait open. The state is always private to the class / > trait at the moment and it already seems to work pretty well. I modified the > NewInspector slightly to show you the proper data (although this needs to be > cleaned up, and state should be sorted per trait), and the OB to compile and > syntax highlight in the right context. > > I didn't test more complex examples yet than what's open, but it's designed > generically enough that I'm confident it does ... euhm ... ;) > > cheers, > Toon > > On 04/03/2011 10:44 AM, Stéphane Ducasse wrote: >> On Apr 2, 2011, at 9:10 PM, Toon Verwaest wrote: >> >>> Hi all, >>> >>> as you know I'm working on stateful traits using my new classbuilder >> no >> Are you? >> >> >>> etc... Now I noticed that methods are highlighted always inside of the >>> context of the class that's active in the class browser. How can I change >>> this? There is already a useful method around to figure out which object it >>> belongs to: >>> >>> SomeClass traitOrClassOfSelector: #aMethod >>> >>> This actually will tell me which trait it comes from. So now I could apply >>> syntax coloring in the context of the trait rather than the class. Since in >>> my implementation state is all private to the trait / class, they should be >>> able to access their own state but not see the state of the other class. >>> This obviously also means that coloring should happen in the correct scope, >>> rather than always in the scope of the class. >>> >>> At the moment the coloring doesn't really make sense ... but then it didn't >>> really matter that much until now. Although if you try to access state in a >>> method coming from a trait, while coding in your IDE you'll probably have >>> the impression you can access your local instvars. I don't really know what >>> the semantics are there... but it seems a bit broken :) >>> >>> cheers, >>> Toon >>> >> > >
