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. Now if you remove this constraint (which is a huge one) and you recompile the method then you can get variable. Now the next important question which is not solve in any of the work is how to initialize traits state in an elegant way. Now in pharo since we duplicate the methods use by traits we can have variable without problem (but we need to recompile the method at composition time). Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
