[Pharo-project] syntax highlighting for (stateful) traits (non-local methods)

Toon Verwaest toon.verwaest at gmail.com
Sun Apr 3 13:25:30 CEST 2011


I just finished building a new image based on the helvetia image.

http://pinocchio.unibe.ch/~tverwaes/PlayOut.tar.gz

The previous image is what I've been developing in, and yes, it's pretty 
annoying... I hope that the new image will perform better. But since I 
already noticed that the new inspector isn't loaded, you don't get a 
proper view on the trait-related objects.

Coloring is still done properly though.

Yes I see, I did forget to implement all the tools to make it work. You 
know... I started the stateful traits implementation on Friday... I'm 
glad that I'm as far as I am ;) However, in the new image I can close 
it. Exceptions are just very slow for some reason.

There are not many comments around, and not enough tests. After I finish 
my paperwriting I'll go over it and document everything! It's a sneak 
preview ... did I mention that? ;)

For the slots, yes there are subclasses of the standard Slot class; and 
they can provide non-standard access.

You might notice that changing a class' layout is a lot faster thanks to 
bytecode level method updates :) Or not, hence I mention it again. 
That's all part of this particular image.

cheers,
Toon

On 04/03/2011 02:19 PM, Alexandre Bergel wrote:
> I tried the image. I hadn't seen such a look for years :-)
>
> StatefulTrait named: #TStatefulTest
> 	layout: PointerLayout
> 	slots: {
> 		#tfirst =>  Slot.
> 		#tsecond =>  Slot.
> 	}
> 	uses: {}
> 	category: #'Slot-Traits-Test'
>
> 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
>
> Cheers,
> Alexandre
>
> 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 ... ;)
>>
>> 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
>>>>
>>




More information about the Pharo-project mailing list