On 24 October 2010 23:45, Stéphane Ducasse <[email protected]> wrote: >>> >>>> >>>>> 2) well, this is difficult to get the money for the butter and the butter >>>>> - we are trying. >>>> >>>> If you can compose classes the way you can add a trait to a class now with >>>> class and optional method level instance+class variable mapping, then >>>> you're done. It would be a lot simpler to use it _and_ it would also be a >>>> lot easier to implement it. Especially the tools part. >>> >>> I'm interested to hear more about that. > > so can you explain what you meant because I did not understand it. > > >>> Tell us more. The problem we faced was >>> - offset access = you cannot reuse bytecode of a trait because the >>> order of the offset can be different in each trait users >> >> If you mean that a CompiledMethod of a trait cannot be added to the class' >> method dictionary, than that's not an issue. The current Trait >> implementation was changed, because shared CompiledMethods caused other >> problems. > > no this is not what I meant > >> If you mean that the same bytecodes can't be used, than that's neither a >> problem, because you can and should be compile the method again. Sharing >> trailer bytes may cause problems. >> So adding a method from a trait to a class is simply recompiling it in the >> class' context. > > this is what we wanted to avoid.
Why? I think it having many benefits comparing to 'compiled once' idea. We're slowly moving towards multiple environemnts, right? So, what if i may want to use same trait in two different environments, and one of its methods using #Foo variable, which depending on environment could be one or another class, or be a classvar with different value. It could be quite powerful thing for testing purposes. Suppose you wanna test something against new implementation of old class. Then you don't need to waste a time and replace Foo -> Bar, you just need to put it in use in different environment, where Foo implemented differently. There are other things.. Suppose my class using different compiler (#compilerClass). It means that any methods in class should be compiled using that compiler. And trait methods should obey the same rule without exception. > Also because you may have to recompile all the other methods of the class > hierarchy because if a trait add an instance > variable then you should recompile the subclasses when a trait get added with > a state in the superclass. > Yes, same as if you adding an extra ivar to existing class, which having subclasses. Nothing really scary. >> Instance variables should be used by name during compilation. If there's a >> name collision then use the instance variable map I mentioned above. > > what is that the instance variable map? > take the time to write an example > >>> - initialization of instances variables at the trait level and the >>> composition at the class levele >> >> You can always rename a trait's method in your class. So if the trait has an >> #initialize method, then simply rename it to #initializeFooBar and send it >> from the class' #initialize method. > > Yes this is what the javascript implementation does but this is not that nice > but may be there is no better solution. > > So indeed we could think about adding state. > > > >> >> >> Levente >> >>> >>>> >>>>> 3) again if nobody does anything and we just all cry on ourselves then >>>>> nothing will happen. >>>> >>>> Tools are a must. No tools - no users. >>> >>> Exact. >>> >>>>> So for now identifying traits and learning is the way. Then we can >>>>> refactor, redesign >>>> >>>> Well, Traits are in Squeak since 2006, IIRC they were available a few >>>> years earlier. So in the last X (at least 4) years the only good candidate >>>> to become a Trait was Magnitude. >>> >>> Come on. >>> I will not answer to such statement because I'm positive thinking. >>> >>> Stef >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
