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
[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
--
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
