> 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.
allMethods from where?
> 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.
Yes, no big challenge to make it work. I agree.
Put a ref to copydown, from strongtalk.
Cheers,
Alexandre
>
> 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
>>>
>
>
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
