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=abstra... =>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