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

Toon Verwaest toon.verwaest at gmail.com
Sun Apr 3 13:33:15 CEST 2011


On 04/03/2011 02:29 PM, Alexandre Bergel wrote:
> I guess that what Stef meant is the following:
> One of the problems when sharing code among mixin and stateful-trait application is that the physical layout of instances varies between mixin applications. (Section 6.5 of http://bergel.eu/download/papers/Berg07e-StatefulTraits.pdf)
>
> We have T.y and C.x
> T has a method #getY, for which its bytecode returns the first slot (i.e., y). If C uses T, the #getY needs to be adapted to return the second slot right?
>
> Cheers,
> Alexandre
Indeed. And this is not different from changing a layout of a class 
having as impact that you have to update the methods.
The default traits implementation already recompiles all methods anyway 
whenever it installs the trait. What I do is, I just let the trait 
compile itself on the subpart of the class that originally defined the 
trait.
Since this subpart is a copy of the original trait (just like the 
default traits does), it also has a COPY of the original layout. In this 
copy, the indices of the slots are updated when they are mixed with the 
class that is going to use the trait. So it's being compiled in the 
scope of the installed version of the trait-layout. So that easily works.

cheers
> On 3 Apr 2011, at 06:23, Toon Verwaest wrote:
>
>>> 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
>> I don't think I fully understand what you are saying...
>>
>> The model is like this at the moment:
>>
>> Every class has a layout attached to it. Layouts that have slots have LayoutScopes. For example, if you have
>>
>> Class A super: Object slots: #(a b c)
>> Class B super: A slots: #(d e)
>>
>> Then you get
>>
>> Class A<->  PointerLayout ->  LayoutClassScope #(a b c) ->  LayoutClassScope #() ->  LayoutEmptyScope
>> Class B<->  PointerLayout ->  LayoutClassScope #(d e) ->  LayoutClassScope #(a b c) ->  LayoutClassScope #() ->  LayoutEmptyScope
>>
>> where LayoutClassScope #(a b c) is shared between the scope of B and the layout of A. The empty LayoutClassScope comes from Object and is shared as well.
>>
>> Now if you get a stateful trait, a stateful trait C with slots #(f) looks like this:
>>
>> StatefulTrait C<->  PointerLayout ->  LayoutTraitScope #(f) ->  LayoutEmptyScope
>>
>> If you were to install the trait C on B, it would become:
>>
>> Class B<->  PointerLayout ->  LayoutClassScope #(d e) ->  LayoutForkScope ->  LayoutClassScope #(a b c) ->  LayoutClassScope #() ->  LayoutEmptyScope
>>
>> where the LayoutForkScope would have sidescopes:
>> LayoutForkScope sideScopes: { LayoutTraitScope #(f) ->  LayoutEmptyScope }
>>
>> Then the classbuilder will build classes by always following the public path. Sidescopes aren't public. When you compile methods on the trait, its scopes are public; but when they are installed, they aren't public since they are sidescopes.
>>
>> However, every method is compiled on the trait or class that provided the selector, so when you install the trait-related method, it will see the state related to the trait. And when the trait is installed, the sidescopes are actually copies of the original traitscope, so the actual fieldindices are updated in the LayoutTraitScope when it's installed.
>>
>> Then how methods get updated based on state changes is at the moment completely unrelated to the trait implementation, since methods are already updated in my class builder based on a MethodModificationModel that knows how the fields have changed. This will use the decompiler/bytecode modification/recompiler to update the methods in place.
>>
>> The only thing that I forgot to do until now is to actually modify all the classes that use a trait, every time the state of a trait changes... But that's straightforward. We just have to ask for the users of the stateful trait and reapply their class modification. That's all nicely modeled already.
>>
>> As for overlapping state from multiple stateful traits.... there is no overlapping state since all state is private to the trait! You can use 2 traits with same slot names. This is no problem at all since the state is only seen by that trait. And their methods are only compiled on that trait, so the methods will always know exactly which of the slots you are referring to.
>>
>> I hope this helps somehow :) Otherwise ... wait for the paper ;)
>>
>> cheers,
>> Toon
>>




More information about the Pharo-project mailing list