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

...

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

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

...

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.

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