Stateful Traits Literature
Locked
 
|
Hi:
A bit off-topic but I think the experts are here, so: Is there somewhere an overview of all traits proposal related to the handling of state? Possibly with a nice taxonomy and visualization? 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Stateful Traits Literature
|
|
Probably the most relevant publications are:
"Traits: A Mechanism for fine-grained Reuse" http://scg.unibe.ch/scgbib?_k=tiFtww66&query=toplas+trait+ducasse&display=abstract => it describes the original trait model "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 "Applying Traits to the Smalltalk Collection Hierarchy" http://scg.unibe.ch/scgbib?_k=NgYx7ipJ&query=Blac03a&display=abstract => Nice application of traits (I know this is not what you're asking for, but this is still a good and relevant paper" Numerous papers have been written on type systems, meta-object protocols, programming environment, all related to traits. scg.unibe.ch will help you find your way. There is small taxonomy in Stef's keynote, given at SC'09. I have also one in some of my presentations if necessary. happy reading, Alexandre On 25 Mar 2010, at 16:32, Stefan Marr wrote: > Hi: > > A bit off-topic but I think the experts are here, so: > > Is there somewhere an overview of all traits proposal related to the > handling of state? > > Possibly with a nice taxonomy and visualization? > > > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Stateful Traits Literature
|
|
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. 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Hi Alexandre:
On 25 Mar 2010, at 23:26, Alexandre Bergel wrote: > 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. Ehm, what does that exactly mean? The resulting class will have a set of instance variables where the name is the identity criterion of the set? A PHP example would look like: class Base{ var $a; } trait T1 { var $a; var $b; } trait T2 { var $a; var $c; } class Composite extends Base { use T1, T2; } and Composite would have the instance variables $a, $b, $c. The problem would be of course that Base, T1, and T2 could use $a for completely different things. Simple, but at the cost of composability/safety. This semantics is also that of my proposal for PHP. Best regards Stefan > > 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Stateful Traits Literature
|
|
>> 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. > Ehm, what does that exactly mean? I read the description some times ago. I might not be accurate on this. > The resulting class will have a set of instance variables where the > name is the identity criterion of the set? > > A PHP example would look like: > > class Base{ > var $a; > } > > trait T1 { > var $a; > var $b; > } > > trait T2 { > var $a; > var $c; > } > > class Composite extends Base { > use T1, T2; > } > > and Composite would have the instance variables $a, $b, $c. I think this is the VW solution. > The problem would be of course that Base, T1, and T2 could use $a > for completely different things. Indeed. We were not able to find a better and simple model. > Simple, but at the cost of composability/safety. > This semantics is also that of my proposal for PHP. Interesting. You designed the same model than the VW guys. Maybe this tells about its simplicity. 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Stateful Traits Literature
|
|
In reply to this post by Alexandre Bergel
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Stateful Traits Literature
|
|
In reply to this post by Stefan Marr-4
Exact
and you can have real problems! Stef > Hi Alexandre: > > > On 25 Mar 2010, at 23:26, Alexandre Bergel wrote: >> 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. > Ehm, what does that exactly mean? > > The resulting class will have a set of instance variables where the name is the identity criterion of the set? > > A PHP example would look like: > > class Base{ > var $a; > } > > trait T1 { > var $a; > var $b; > } > > trait T2 { > var $a; > var $c; > } > > class Composite extends Base { > use T1, T2; > } > > and Composite would have the instance variables $a, $b, $c. > The problem would be of course that Base, T1, and T2 could use $a for completely different things. > > Simple, but at the cost of composability/safety. > This semantics is also that of my proposal for PHP. > > Best regards > Stefan > >> >> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Stateful Traits Literature
|
|
In reply to this post by Stéphane Ducasse
On Mar 26, 2010, at 9:23 AM, Stéphane Ducasse wrote: > 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. > > The thing is that this can only change when you change class structure, which does not happen often. For Reflectivity, we did an experimental "in Image" AST->BC "JIT", where things like that happend automatically. (you can just invalidate the CM cache on any change in the class hierarchy). I guess one could come up with a more low-level story that would be less intrusive but nevertheless would allow for late-binding the offsets. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Stateful Traits Literature
|
|
>
>> 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. >> >> > So I wonder if we should not think about late-binding ivar names to offsets... yes that would be cool > The thing is that this can only change when you change class structure, which does not happen often. > > For Reflectivity, we did an experimental "in Image" AST->BC "JIT", where things like that happend automatically. > (you can just invalidate the CM cache on any change in the class hierarchy). > > I guess one could come up with a more low-level story that would be less intrusive but nevertheless would > allow for late-binding the offsets. For me I would like to play with that with first class instance variables. > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Stateful Traits Literature
|
|
In reply to this post by Alexandre Bergel
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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Stateful Traits Literature
|
|
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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |