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=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
-- 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.