On Mar 26, 2010, at 9:23 AM, Stéphane Ducasse wrote:
> Alex
>
> the context in which the solution were made is as important as the
> solution....
>
>> I agree. Most of our extensions are really complex.
>>
>> In my opinion, traits must define variable. Else it defeats the whole
>> purpose of having a better modularity. Each time I use traits, I need
>> variables.
>>
>> The solution of Visualworks was quite simple, and I think it makes sense in
>> most of the practical cases: when you compose traits, you simply concatenate
>> the variables defined in the composed traits with the variables defined in
>> the class. Duplicated names are then removed. Easy.
>
> you can only do that if you recompile the complete method so that offsets are
> aligned between the class format
> and the instance variable use in the method and you have one method per trait
> usage.
>
> So what I like in the first trait model is that methods were share so you got
> reuse for FREE.
>
>
So I wonder if we should not think about late-binding ivar names to offsets...
The thing is that this can only change when you change class structure, which
does not happen often.
For Reflectivity, we did an experimental "in Image" AST->BC "JIT", where things
like that happend automatically.
(you can just invalidate the CM cache on any change in the class hierarchy).
I guess one could come up with a more low-level story that would be less
intrusive but nevertheless would
allow for late-binding the offsets.
Marcus
--
Marcus Denker -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
