On Mar 26, 2010, at 11:40 AM, Simon Denier wrote: > > On 25 mars 2010, at 23:26, Alexandre Bergel wrote: > >> 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. > > > Funny, I also need state when I use traits, but in a more conservative > approach: by default, I prefer states to be separated and possibly > duplicated. I think it's easier to notice that state needs to be shared than > to notice a weird bug happens because state is shared in a wrong way. If you > need state to be shared, it's easy to refactor the accessors to access the > same state. But it's my completely insubstantial opinion
Come on I like it. This is a cool remark. I will think about that. > (it's a deal between sharing states to have easy consistency and having > compatible constraints (pre/post conditions) on shared state) > > As for the argument with recompiling methods, it's the same deal right now > because required methods need to be overridden right? The rule of thumb is > that you should not access state directly, but only through pure accessors. > So only pure accessors need to be recompiled. But the stuff discussed by > Markus could be helpful. > > As for traitInitialization, I have my ideas but I guess there is no silver > bullet. > > >> >> Cheers, >> Alexandre >> >> >> On 25 Mar 2010, at 17:19, Stefan Marr wrote: >> >>> Hi Alexandre: >>> >>> >>> Thanks. >>> I have read all these papers already, but kind of hoped that there is >>> something I missed so far. >>> >>> On 25 Mar 2010, at 23:00, Alexandre Bergel wrote: >>>> "Stateful Traits and their Formalization" >>>> http://scg.unibe.ch/scgbib?_k=OiaJOIuA&query=Berg08e&display=abstract >>>> => It describes stateful traits >>>> >>>> "User-Changeable Visibility: Resolving Unanticipated Name Clashes in >>>> Traits" >>>> http://scg.unibe.ch/scgbib?_k=NNRwidu5&query=freezable+traits&display=abstract >>>> =>Freezable traits >>>> >>>> "Adding State and Visibility Control to Traits using Lexical Nesting" >>>> http://scg.unibe.ch/scgbib?_k=J-wbMltV&query=tom+cutsem+bergel >>>> => Traits for a class-less language >>> My problem is, that these proposals involve a lot additional complexity. >>> And, Tom's paper is not really applicable to PHP. PHP just does not have a >>> real notion of lexical context. >>> >>> Thanks >>> Stefan >>> >>> >>> >>> -- >>> Stefan Marr >>> Software Languages Lab >>> Vrije Universiteit Brussel >>> Pleinlaan 2 / B-1050 Brussels / Belgium >>> http://soft.vub.ac.be/~smarr >>> Phone: +32 2 629 2974 >>> Fax: +32 2 629 3525 >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
