[Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
alexandre.bergel at me.com
Sun Apr 3 14:19:09 CEST 2011
I tried the image. I hadn't seen such a look for years :-)
StatefulTrait named: #TStatefulTest
#tfirst => Slot.
#tsecond => Slot.
I checked what layout: is about. StatefulTrait is a dry in terms of comments :-)
Why do you have "=> Slot" ? What can tfirst be else, if not a slot? Can you specialize the slots to use a particular layout?
I played a bit with your image. I cannot access tfirst in MyFirstTest. Your implementation is conform to the policy you defined above.
Your image is a bit unstable. I tried to press the tab key for autocompletion, and got some debuggers that I couldn't close. I misspelled aMethod with aMethdo, and got plenty of debuggers related to QQParser
On 3 Apr 2011, at 05:34, Toon Verwaest wrote:
> Oh yes.. I am :)
> 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 ... ;)
> 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
>> 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 :)
Alexandre Bergel http://www.bergel.eu
More information about the Pharo-project