> >> 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...
yes that would be cool > 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. For me I would like to play with that with first class instance variables. > _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
