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 (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 >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
