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.