cool :) yeah, next tool generation (glamoroust?) should be made taking traits in mind best, Esteban El 15/02/2012, a las 7:45a.m., Stéphane Ducasse escribió:

Indeed. Now I would love that we rethink our trait implementation and tool support but no time.

On Feb 15, 2012, at 6:40 AM, blake wrote:

...

This is kinda cool:

http://phpmaster.com/using-traits-in-php-5-4/

On Feb 15, 2012, at 4:55 PM, Damien Cassou wrote:

On Wed, Feb 15, 2012 at 11:45 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

Indeed. Now I would love that we rethink our trait implementation and tool support but no time.

Give me a position, I will take care of that :-)

we have one :) and indeed it would be reeeallllllly cool. Stef

Hi Hernan: On 15 Feb 2012, at 23:30, Hernan Wilkinson wrote:

what is the difference with the current trait implementation in pharo? I could not see the difference...

There are only cosmetic differences. (If I remember correctly what Pharo's traits entail.) Most importantly, you cannot exclude arbitrary methods from a trait. Thus, there is no exclude operator. Instead, conflicts are resolved by explicitly stating which method wins a conflict with the insteadof keyword. And, because PHP has a much more dynamic notion of object fields/slots, I added a couple of rules to make that manageable. https://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate The main idea is, break on obviously incompatible things, and leave the rest to the normal dynamic semantics. (which means, we do not have a solution for state). Best regards 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

I have an idea about the state issue in traits, maybe you thought about it too... I was thinking that the definition of representing something as state or not should be responsibility of the implementation, that is the class (nothing new here), so we delay that decision until the trait is used. So, maybe what we need is a way to indicate that a message send in a trait is not really that in a class... For example: TraitA>>m1 ^self name first Object subclass: #ClassA uses: #TraitA mapping: (MessageSendToInstanceVariable from: #name to: 'firstName') ... bla bla. So, #m1 in ClassA would look like: ClassA>>m1 ^firstName first Of course this implies some complexity when copying the behavior from the trait to the class (we can not use the same compiled method), also maintaining the relationship with changes on the trait (what happens if #m1 is changed in TraitA and does not send #name anymore), etc. First class slot (a la Self) would be a nicer solution, but I feel that that implies a more radical change on the object model, vm, etc. and also has the disadvantages of making all state public (unless something is done to avoid that). At the same time, I would like to point out that having subclassing and traits at the same time as sharing mechanism is kind of confusing, programmers do not know which one is better to use, should I subclass or use a trait? how I'm sure which one is better? etc. We talk about this when you came to Argentina, do you remember? A student did his tesis about removing subclassing and using only traits as sharing tool, but the results were not as good as I expected (sadly, the thesis is written in Spanish...) Anyway, my two cents Hernan. On Thu, Feb 16, 2012 at 4:56 AM, Stéphane Ducasse <stephane.ducasse@inria.fr

wrote:

On Feb 15, 2012, at 11:30 PM, Hernan Wilkinson wrote:

...

what is the difference with the current trait implementation in pharo? I could not see the difference…

Stefan replied but what I wanted to say is that I would like to have the time to see how we can introduce more nicely traits. Right now there are edges where this is ugly and also rethink the system. I think that if we would have first class slots we could have traits with state in a much better fashion.

Stef

...

On Wed, Feb 15, 2012 at 7:45 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote: Indeed. Now I would love that we rethink our trait implementation and tool support but no time.

On Feb 15, 2012, at 6:40 AM, blake wrote:

...

This is kinda cool:

http://phpmaster.com/using-traits-in-php-5-4/

-- Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

It looks interesting, but how this relates to the state issue? On Thu, Feb 16, 2012 at 12:35 PM, Nicolas Passerini <npasserini@gmail.com>wrote:

I think it would be very nice to be able to apply a trait directly to an object, without having to create a new class. This is possible for example in scala:

val myObject = new MyClass with MyTrait

I have programmed a simple implementation in Pharo which allows you to do:

myObject := (MyClass with: MyTrait) new.

The implementation is only a proof of concept and has some issues that should be addressed before being able to use it in a real program, but I can make it available if someone is interested.

What do you think about this?

On Thu, Feb 16, 2012 at 11:04 AM, Hernan Wilkinson < hernan.wilkinson@10pines.com> wrote:

...

I have an idea about the state issue in traits, maybe you thought about it too... I was thinking that the definition of representing something as state or not should be responsibility of the implementation, that is the class (nothing new here), so we delay that decision until the trait is used. So, maybe what we need is a way to indicate that a message send in a trait is not really that in a class... For example:

TraitA>>m1

^self name first

Object subclass: #ClassA uses: #TraitA mapping: (MessageSendToInstanceVariable from: #name to: 'firstName') ... bla bla.

So, #m1 in ClassA would look like:

ClassA>>m1

^firstName first

Of course this implies some complexity when copying the behavior from the trait to the class (we can not use the same compiled method), also maintaining the relationship with changes on the trait (what happens if #m1 is changed in TraitA and does not send #name anymore), etc. First class slot (a la Self) would be a nicer solution, but I feel that that implies a more radical change on the object model, vm, etc. and also has the disadvantages of making all state public (unless something is done to avoid that).

At the same time, I would like to point out that having subclassing and traits at the same time as sharing mechanism is kind of confusing, programmers do not know which one is better to use, should I subclass or use a trait? how I'm sure which one is better? etc. We talk about this when you came to Argentina, do you remember? A student did his tesis about removing subclassing and using only traits as sharing tool, but the results were not as good as I expected (sadly, the thesis is written in Spanish...)

Anyway, my two cents Hernan.

On Thu, Feb 16, 2012 at 4:56 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:

...

On Feb 15, 2012, at 11:30 PM, Hernan Wilkinson wrote:

...

what is the difference with the current trait implementation in pharo? I could not see the difference…

Stefan replied but what I wanted to say is that I would like to have the time to see how we can introduce more nicely traits. Right now there are edges where this is ugly and also rethink the system. I think that if we would have first class slots we could have traits with state in a much better fashion.

Stef

...

On Wed, Feb 15, 2012 at 7:45 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote: Indeed. Now I would love that we rethink our trait implementation and tool support but no time.

On Feb 15, 2012, at 6:40 AM, blake wrote:

...

This is kinda cool:

http://phpmaster.com/using-traits-in-php-5-4/

-- Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

oh, ok. Yeah, I like the idea, but I agree with stef that you need tool support... an environment like Self for example On Thu, Feb 16, 2012 at 6:11 PM, Nicolas Passerini <npasserini@gmail.com>wrote:

On Thu, Feb 16, 2012 at 4:20 PM, Hernan Wilkinson < hernan.wilkinson@10pines.com> wrote:

...

It looks interesting, but how this relates to the state issue?

It is not directly related to the state issue. Just to different trait models, I think that it would be a nice yet very simple enhancement, to be able add a trait directly to an object at instantiation time istead of always having to create a new class.

I apologise if my mail was confusing.

However mi little traits extension has also something to say about state. When I do: myObject := (*MyClass with: MyTrait*) new

The class of myObject is created dynamically, so I can have MyTrait declaring its required state an then the instance variables are created automatically. It is also a little extension to declaring required methods.

-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

On Thu, Feb 16, 2012 at 7:35 PM, Hernan Wilkinson <hernan.wilkinson@10pines.com> wrote: oh, ok. Yeah, I like the idea, but I agree with stef that you need tool support... an environment like Self for example

I agree, it would need some tool support, I didn't have time to work on it yet.

Which kind of tool support do you think we would need? (I love many of the ideas in Self, but the environment is not one of them.)

One thing I would like to put some work on is refactorings for traits (including some not necessarily related with the previous idea).

Indeed. I do not see why we would like to have object level trait. May be in ruby but not in class-based language or this is not a class based language anymore.

On 17 February 2012 09:57, Frank Shearar <frank.shearar@gmail.com> wrote:

Smalltalk _uses_ classes, but there's no "class" in "everything's an object, and objects communicate by sending messages".

That aside, while Ruby _supports_ something like "object level trait" in the form of eigenclasses, mixins seem much more like how Gilad describes them, and "parameterised subclasses" - classes that take a superclass as parameter.

That means that Array withTrait: IdentityHashed. Object withTrait: IdentityHashed creates _classes_, something like this:

      Array                Object         ^                    ^         |                    |  (IdentityHashed)     (IdentityHashed)

Yes, i think this is right direction, by creating an anonymous subclasses, which holding additional state/methods added by trait. One of problems however is of course different object format(s): i.e. applying a stateful trait to ByteArray <- Trait is not the same as applying it to: Array <- Trait and simply impossible to SmallInteger <- Trait :)

frank

On 17 February 2012 05:18, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

...

On Thu, Feb 16, 2012 at 7:35 PM, Hernan Wilkinson <hernan.wilkinson@10pines.com> wrote: oh, ok. Yeah, I like the idea, but I agree with stef that you need tool support... an environment like Self for example

I agree, it would need some tool support, I didn't have time to work on it yet.

Which kind of tool support do you think we would need? (I love many of the ideas in Self, but the environment is not one of them.)

One thing I would like to put some work on is refactorings for traits (including some not necessarily related with the previous idea).

Indeed.

I do not see why we would like to have object level trait. May be in ruby but not in class-based language or this is not a class based language anymore.

-- Best regards, Igor Stasenko.

Alejandro Gonzalez did some work about it around 2008, if you want I can contact you with him. He also implemented some nice refactorings. On Thu, Feb 16, 2012 at 9:02 PM, Nicolas Passerini <npasserini@gmail.com>wrote:

On Thu, Feb 16, 2012 at 7:35 PM, Hernan Wilkinson < hernan.wilkinson@10pines.com> wrote:

...

oh, ok. Yeah, I like the idea, but I agree with stef that you need tool support... an environment like Self for example

I agree, it would need some tool support, I didn't have time to work on it yet.

Which kind of tool support do you think we would need? (I love many of the ideas in Self, but the environment is not one of them.)

One thing I would like to put some work on is refactorings for traits (including some not necessarily related with the previous idea).

-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

Le 16 février 2012 22:09, Stéphane Ducasse <stephane.ducasse@inria.fr> a écrit :

On Feb 16, 2012, at 4:35 PM, Nicolas Passerini wrote:

...

I think it would be very nice to be able to apply a trait directly to an object, without having to create a new class. This is possible for example in scala:

      val myObject = new MyClass with MyTrait

I have programmed a simple implementation in Pharo which allows you to do:

myObject := (MyClass with: MyTrait) new.

The implementation is only a proof of concept and has some issues that should be addressed before being able to use it in a real program, but I can make it available if someone is interested.

What do you think about this?

I do not think that I want that. Because:        what about tools support?        I do not see the use case.

Now you can do prototypes for fun. Stef

I find it interesting if ever you create plenty composition options and don't want to provide a static implementation for the whole set of partitions N composable traits => (2 raisedTo: N) partitions... This also avoid to have a whole zoo of class names. But then, each instance will have it's own class copy created on the gly, which might be suboptimal. Unless we cache... Here is a dumb example (with stateful traits): you want to stop wasting 12 bits of identity hash in each object header, when you only rarely put these objects in identity hashed collections... You thus add the trait on the fly IdentityDictionary at: key put: value key acquireIdentityHash. snip... Object>>acquireIdentityHash ^self becomeForward: ((self class withTrait: IdentityHashed) basicNew copyStatesFrom: self; initializeIdentityHash) IdentityHashed>>acquireIdentityHash ^self IdentityHashed>>initializeIdentityHash identityHash ifNil: [identityHash := self createRandomIdentityHash] IdentityHashed>>identityHash ^identityHash If this was possible, you would of course not duplicate each class with its IdentityHashed variant :) Nicolas

if you use an object model a la Self, there is no difference between an instance variable and a method from the "sender" point of view. So, in this code "self name", name could be implemented as a "data slot" (a slot that references an object) or a "method slot", it is up to the receiver. So, the sender always sends the message #name, no matter if name is implemented as method or "variable". At the end it is not first class slots what solves the problem but the uniformity of using only message send to represent computation (no variable assingments, etc). So, going to the trait example, if the trait says "self name", the class that uses that trait could implement "name" as a data slot or method slot, it does not matter to the trait and therefore the trait is state agnostic... at least that is what I understood from Stef comment :-), but may be he meant other thing! :-) On Thu, Feb 16, 2012 at 2:11 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:

On Thu, Feb 16, 2012 at 3:04 PM, Hernan Wilkinson < hernan.wilkinson@10pines.com> wrote:

...

I have an idea about the state issue in traits, maybe you thought about it too... I was thinking that the definition of representing something as state or not should be responsibility of the implementation, that is the class (nothing new here), so we delay that decision until the trait is used. So, maybe what we need is a way to indicate that a message send in a trait is not really that in a class... For example:

TraitA>>m1

^self name first

Object subclass: #ClassA uses: #TraitA mapping: (MessageSendToInstanceVariable from: #name to: 'firstName') ... bla bla.

So, #m1 in ClassA would look like:

ClassA>>m1

^firstName first

Of course this implies some complexity when copying the behavior from the trait to the class (we can not use the same compiled method), also maintaining the relationship with changes on the trait (what happens if #m1 is changed in TraitA and does not send #name anymore), etc. First class slot (a la Self) would be a nicer solution,

For the slower ones ... why would first class slots solves this? I didn't get it.

Thanks!

...

but I feel that that implies a more radical change on the object model, vm, etc. and also has the disadvantages of making all state public (unless something is done to avoid that).

At the same time, I would like to point out that having subclassing and traits at the same time as sharing mechanism is kind of confusing, programmers do not know which one is better to use, should I subclass or use a trait? how I'm sure which one is better? etc. We talk about this when you came to Argentina, do you remember? A student did his tesis about removing subclassing and using only traits as sharing tool, but the results were not as good as I expected (sadly, the thesis is written in Spanish...)

Anyway, my two cents Hernan.

On Thu, Feb 16, 2012 at 4:56 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:

...

On Feb 15, 2012, at 11:30 PM, Hernan Wilkinson wrote:

...

what is the difference with the current trait implementation in pharo? I could not see the difference…

Stefan replied but what I wanted to say is that I would like to have the time to see how we can introduce more nicely traits. Right now there are edges where this is ugly and also rethink the system. I think that if we would have first class slots we could have traits with state in a much better fashion.

Stef

...

On Wed, Feb 15, 2012 at 7:45 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote: Indeed. Now I would love that we rethink our trait implementation and tool support but no time.

On Feb 15, 2012, at 6:40 AM, blake wrote:

...

This is kinda cool:

http://phpmaster.com/using-traits-in-php-5-4/

-- Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

-- Mariano http://marianopeck.wordpress.com

-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina