Smalltalk › Pharo › Pharo Smalltalk Users

Trait composition on runtime

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

21 messages Options

NorbertHartl

Trait composition on runtime

Does pharo support runtime trait composition or does it only work on class definition time. I mean something like

anObject addTrait: MySpecialCapability
anObject removeTrait: MySpecialCapability

Norbert

Jorge Ressia

Re: Trait composition on runtime

Hi Norbert,

It sounds like you want something like talents Talents http://scg.unibe.ch/research/bifrost/talents.

However, there is no running version on pharo 3.0 yet.

I am not aware of work on object-specific traits, I could be wrong though.

Cheers,

On Thu, Aug 22, 2013 at 3:23 PM, Norbert Hartl <[hidden email]> wrote:

Does pharo support runtime trait composition or does it only work on class definition time. I mean something like

anObject addTrait: MySpecialCapability
anObject removeTrait: MySpecialCapability

Norbert

--
Jorge Ressia
www.jorgeressia.com

Sebastian Tleye

Re: Trait composition on runtime

Hi Norbert,

You can do anObject setTraitComposition: aTraitComposition but only works for behavior objects

2013/8/22 Jorge Ressia <[hidden email]>

Hi Norbert,

It sounds like you want something like talents Talents http://scg.unibe.ch/research/bifrost/talents.

However, there is no running version on pharo 3.0 yet.

I am not aware of work on object-specific traits, I could be wrong though.

Cheers,

On Thu, Aug 22, 2013 at 3:23 PM, Norbert Hartl <[hidden email]> wrote:

Does pharo support runtime trait composition or does it only work on class definition time. I mean something like

anObject addTrait: MySpecialCapability
anObject removeTrait: MySpecialCapability

Norbert

--
Jorge Ressia
www.jorgeressia.com

Stéphane Ducasse

Re: Trait composition on runtime

In reply to this post by NorbertHartl

On Aug 22, 2013, at 3:23 PM, Norbert Hartl <[hidden email]> wrote:

> Does pharo support runtime trait composition or does it only work on class definition time. I mean something like
>
> anObject addTrait: MySpecialCapability
> anObject removeTrait: MySpecialCapability

Nope :)
traits are static :)
>
> Norbert
>
>

NorbertHartl

Re: Trait composition on runtime

Am 22.08.2013 um 16:25 schrieb Stéphane Ducasse <[hidden email]>:

>
> On Aug 22, 2013, at 3:23 PM, Norbert Hartl <[hidden email]> wrote:
>
>> Does pharo support runtime trait composition or does it only work on class definition time. I mean something like
>>
>> anObject addTrait: MySpecialCapability
>> anObject removeTrait: MySpecialCapability
>
> Nope :)
> traits are static :)

Sad. You know I was not asking about trait but about runtime composable behavior. I'm not sure what you mean with "traits are static". If traits are static in pharo that's fine. If you think traits are static by design then I was looking for something that has a different name :)

Norbert
>>
>> Norbert
>
>

Stéphane Ducasse

Re: Trait composition on runtime

>>
>>> Does pharo support runtime trait composition or does it only work on class definition time. I mean something like
>>>
>>> anObject addTrait: MySpecialCapability
>>> anObject removeTrait: MySpecialCapability
>>
>> Nope :)
>> traits are static :)
>
> Sad. You know I was not asking about trait but about runtime composable behavior. I'm not sure what you mean with "traits are static". If traits are static in pharo that's fine. If you think traits are static by design then I was looking for something that has a different name :)

:)

What I think is that traits are cool but not powerful enough but even the ones that we have right now
makes the system more complex and this is what makes me sad :) I would prefer something more powerful
and simpler: the graal :)

Stef

jfabry

Re: Trait composition on runtime

In reply to this post by NorbertHartl

Norbert, do you want to be able to programmatically add and remove traits at runtime? I wrote a small utility for that a while ago that still works OK (All tests are still green in 2.0). See http://www.squeaksource.com/TraitsApplication.html

Hope this helps.

On Aug 22, 2013, at 1:19 PM, Norbert Hartl <[hidden email]> wrote:

>
> Sad. You know I was not asking about trait but about runtime composable behavior. I'm not sure what you mean with "traits are static". If traits are static in pharo that's fine. If you think traits are static by design then I was looking for something that has a different name :)

---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD lab - Computer Science Department (DCC) - University of Chile

Juraj Kubelka-5

Re: Trait composition on runtime

In reply to this post by Stéphane Ducasse

CONTENTS DELETED

The author has deleted this message.

jfabry

Re: Trait composition on runtime

I think that indeed you touch on 2 important cultural issues, first the entire "Worse is Better" discussion (started by Richard Gabriel), and second that IDE support is key for getting more advanced forms of modularity in use. In my experience, sadly, Traits support in Pharo has been less than ideal. In 2.0 it has improved though, so I am happy about that.

On Aug 22, 2013, at 4:03 PM, Juraj Kubelka <[hidden email]> wrote:

> Interesting. Is it only problem of system complexity? I have the impression the problem is that people do not changed his mind in order to think in traits. (or generally speaking in any other system like mixins, aspects, etc.) It looks like objects with single-inheritance are simple and powerful enough.
>
> Or maybe any system like traits have not come with efficient enough IDE?

---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD lab - Computer Science Department (DCC) - University of Chile

Juraj Kubelka-5

Re: Trait composition on runtime

CONTENTS DELETED

The author has deleted this message.

jfabry

Re: Trait composition on runtime

Define 'widely used' and 'is it necessary' ;-)

I would say, from the point of view of an Aspects guy (me), that a noticeable influence in the acceptance of the language AspectJ is that they have an acceptable level of IDE support. And there is no escaping the fact that sometimes the decomposition of the system will lead to code that is scattered around different places. Single inheritance with objects is not a silver bullet. But it can be 'good enough' … worse is better ...

On Aug 22, 2013, at 4:25 PM, Juraj Kubelka <[hidden email]> wrote:

> Is there any "more complex" system which is widely used? I am interested if it has a sense to spend time on researching something better than single-inheritance OOP, traits, etc. Because "Worse is Better" is maybe the point.
>
> For example I found easier to improve (optimize) an existing application structure by using traits/aspects/etc. But for a new parts of system it looks easier to think in single-inheritance-objects. About optimisation developers think when it is necessary. Is it?
>
> Cheers,
> Jura
>
> El 22-08-2013, a las 16:11, Johan Fabry <[hidden email]> escribió:
>
>>
>> I think that indeed you touch on 2 important cultural issues, first the entire "Worse is Better" discussion (started by Richard Gabriel), and second that IDE support is key for getting more advanced forms of modularity in use. In my experience, sadly, Traits support in Pharo has been less than ideal. In 2.0 it has improved though, so I am happy about that.
>>
>> On Aug 22, 2013, at 4:03 PM, Juraj Kubelka <[hidden email]> wrote:
>>
>>> Interesting. Is it only problem of system complexity? I have the impression the problem is that people do not changed his mind in order to think in traits. (or generally speaking in any other system like mixins, aspects, etc.) It looks like objects with single-inheritance are simple and powerful enough.
>>>
>>> Or maybe any system like traits have not come with efficient enough IDE?
>>
>>
>>
>> ---> Save our in-boxes! http://emailcharter.org <---
>>
>> Johan Fabry - http://pleiad.cl/~jfabry
>> PLEIAD lab - Computer Science Department (DCC) - University of Chile
>>
>>
>

---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD lab - Computer Science Department (DCC) - University of Chile

NorbertHartl

Re: Trait composition on runtime

In reply to this post by Jorge Ressia

Jorge,

Am 22.08.2013 um 15:28 schrieb Jorge Ressia <[hidden email]>:

Hi Norbert,

It sounds like you want something like talents Talents http://scg.unibe.ch/research/bifrost/talents.
However, there is no running version on pharo 3.0 yet.

I am not aware of work on object-specific traits, I could be wrong though.

you might be right. The way talents work is basically what I am asking for. I never got into depth with talents and thought it is much more than adjustment of behavior on per object base. I was hoping there are some easy things available to use in order to modify behavior lookup. I should have a look at talents. Thanks for the tip.

Norbert

Cheers,

On Thu, Aug 22, 2013 at 3:23 PM, Norbert Hartl <[hidden email]> wrote:

Does pharo support runtime trait composition or does it only work on class definition time. I mean something like

anObject addTrait: MySpecialCapability
anObject removeTrait: MySpecialCapability

Norbert

--
Jorge Ressia
www.jorgeressia.com

NorbertHartl

Re: Trait composition on runtime

In reply to this post by jfabry

Am 22.08.2013 um 20:29 schrieb Johan Fabry <[hidden email]>:

>
> Norbert, do you want to be able to programmatically add and remove traits at runtime? I wrote a small utility for that a while ago that still works OK (All tests are still green in 2.0). See http://www.squeaksource.com/TraitsApplication.html
>
> Hope this helps.
>
Thanks. My high hopes were to get something to tweak behavior composition on an object base. I did not have a look at TraitsApplication, yet. But it sounds like it operates on behavior. The background of my inquiry is just a thought experiment. Thinking about it I might get away with a hacked version of cloning classes, adjust the trait composition and reassign the class of the objects I need to work on.

Norbert

> On Aug 22, 2013, at 1:19 PM, Norbert Hartl <[hidden email]> wrote:
>
>>
>> Sad. You know I was not asking about trait but about runtime composable behavior. I'm not sure what you mean with "traits are static". If traits are static in pharo that's fine. If you think traits are static by design then I was looking for something that has a different name :)
>
>
>
> ---> Save our in-boxes! http://emailcharter.org <---
>
> Johan Fabry - http://pleiad.cl/~jfabry
> PLEIAD lab - Computer Science Department (DCC) - University of Chile
>
>

NorbertHartl

Re: Trait composition on runtime

In reply to this post by Stéphane Ducasse

Am 22.08.2013 um 20:12 schrieb Stéphane Ducasse <[hidden email]>:

>>>
>>>> Does pharo support runtime trait composition or does it only work on class definition time. I mean something like
>>>>
>>>> anObject addTrait: MySpecialCapability
>>>> anObject removeTrait: MySpecialCapability
>>>
>>> Nope :)
>>> traits are static :)
>>
>> Sad. You know I was not asking about trait but about runtime composable behavior. I'm not sure what you mean with "traits are static". If traits are static in pharo that's fine. If you think traits are static by design then I was looking for something that has a different name :)
>
> :)
>
> What I think is that traits are cool but not powerful enough but even the ones that we have right now
> makes the system more complex and this is what makes me sad :) I would prefer something more powerful
> and simpler: the graal :)
>

Agreed. A simple prove that there is a more powerful approach to this small-shared-state-thingies-we-love exists would be nice :)

Norbert

NorbertHartl

Re: Trait composition on runtime

In reply to this post by Juraj Kubelka-5

Am 22.08.2013 um 22:03 schrieb Juraj Kubelka <[hidden email]>:

>
> El 22-08-2013, a las 14:12, Stéphane Ducasse <[hidden email]> escribió:
>
>>>>
>>>>> Does pharo support runtime trait composition or does it only work on class definition time. I mean something like
>>>>>
>>>>> anObject addTrait: MySpecialCapability
>>>>> anObject removeTrait: MySpecialCapability
>>>>
>>>> Nope :)
>>>> traits are static :)
>>>
>>> Sad. You know I was not asking about trait but about runtime composable behavior. I'm not sure what you mean with "traits are static". If traits are static in pharo that's fine. If you think traits are static by design then I was looking for something that has a different name :)
>>
>> :)
>>
>> What I think is that traits are cool but not powerful enough but even the ones that we have right now
>> makes the system more complex and this is what makes me sad :) I would prefer something more powerful
>> and simpler: the graal :)
>>
>> Stef
>
> Interesting. Is it only problem of system complexity? I have the impression the problem is that people do not changed his mind in order to think in traits. (or generally speaking in any other system like mixins, aspects, etc.) It looks like objects with single-inheritance are simple and powerful enough.
>

I think system complexity matters a lot because it is one of the facts why software systems fail. If "people do not change their minds" it is a question about the timeframe you watch people not adjusting. People do not like to change but if things are there they may adjust to it (slowly). Being fast in judging something down is as good as not recognizing that an approach is suboptimal. To be honest while looking at all the people I've met in my career I couldn't find that people have adjusted to OO (,yet). This could indeed be a sign that the whole approach is not applicable.

I found traits an interesting approach in the beginning but I don't really like them how they are. I'm not sure if this is dependent on traits or the fact that I have doubts that classes are a good approach. At least I would like to have a looser/lighter approach to compose some behavior at runtime. Just like we do not only have compiled methods but also blocks.
To me behavior composition is less about defining types like we do with static traits. It is more about adjusting behavior at runtime depending on the execution context.
We have a single inheritance system that is good. And we use a lot of delegations to escape the limits of this approach. Bringing this spirit closer to the language enables IMHO more expressive programs and could enable a lot more things.

my 2 cents,

Norbert
> Or maybe any system like traits have not come with efficient enough IDE?
>
> Cheers,
> Jura

Stéphane Ducasse

Re: Trait composition on runtime

In reply to this post by NorbertHartl

Hi Norbert,

It sounds like you want something like talents Talents http://scg.unibe.ch/research/bifrost/talents.
However, there is no running version on pharo 3.0 yet.

I am not aware of work on object-specific traits, I could be wrong though.

you might be right. The way talents work is basically what I am asking for. I never got into depth with talents and thought it is much more than adjustment of behavior on per object base. I was hoping there are some easy things available to use in order to modify behavior lookup. I should have a look at talents. Thanks for the tip.

would strategy not solve your problem?

Stef

Stéphane Ducasse

Re: Trait composition on runtime

In reply to this post by Juraj Kubelka-5

IDE is support key as Johan mentioned.
Then the question is what is the correct granularity that will suit future users of a trait.
Stef

NorbertHartl

Re: Trait composition on runtime

In reply to this post by Stéphane Ducasse

Am 23.08.2013 um 09:34 schrieb Stéphane Ducasse <[hidden email]>:

Hi Norbert,

It sounds like you want something like talents Talents http://scg.unibe.ch/research/bifrost/talents.
However, there is no running version on pharo 3.0 yet.

I am not aware of work on object-specific traits, I could be wrong though.

you might be right. The way talents work is basically what I am asking for. I never got into depth with talents and thought it is much more than adjustment of behavior on per object base. I was hoping there are some easy things available to use in order to modify behavior lookup. I should have a look at talents. Thanks for the tip.

would strategy not solve your problem?

Sure if I would have an actual problem I would use strategy to mitigate the problem. With strategy you can extend the single dimensionality of single inheritance but you cannot acquire new behavior. Or better it is even more cumbersome if you use it to make it acquire new things.

Or different said: If there is something like a design pattern that is used really often it could be a good idea if the language would support this out of the box, right? Somewhere in between is the reason why I was asking :)

Norbert

jfabry

Re: Trait composition on runtime

On Aug 23, 2013, at 3:48 AM, Norbert Hartl <[hidden email]> wrote:

>> would strategy not solve your problem?
>>
> Sure if I would have an actual problem I would use strategy to mitigate the problem. With strategy you can extend the single dimensionality of single inheritance but you cannot acquire new behavior. Or better it is even more cumbersome if you use it to make it acquire new things.
> Or different said: If there is something like a design pattern that is used really often it could be a good idea if the language would support this out of the box, right? Somewhere in between is the reason why I was asking :)

Metaprogramming is your friend :-P

Actually this is only half jokingly … one of the ideas of metaprogramming is that the programmer can mold the semantics of the language to his/her liking depending on the task at hand. This (amongst others) is why we can do so many cool things in Smalltalk. For example, when you have a more concrete case of what you are looking for you can build something with method wrappers, or override DNU :-) to do your thing ...

---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD lab - Computer Science Department (DCC) - University of Chile

NorbertHartl

Re: Trait composition on runtime

Am 23.08.2013 um 15:44 schrieb Johan Fabry <[hidden email]>:

>
> On Aug 23, 2013, at 3:48 AM, Norbert Hartl <[hidden email]> wrote:
>
>>> would strategy not solve your problem?
>>>
>> Sure if I would have an actual problem I would use strategy to mitigate the problem. With strategy you can extend the single dimensionality of single inheritance but you cannot acquire new behavior. Or better it is even more cumbersome if you use it to make it acquire new things.
>> Or different said: If there is something like a design pattern that is used really often it could be a good idea if the language would support this out of the box, right? Somewhere in between is the reason why I was asking :)
>
> Metaprogramming is your friend :-P
>
> Actually this is only half jokingly … one of the ideas of metaprogramming is that the programmer can mold the semantics of the language to his/her liking depending on the task at hand. This (amongst others) is why we can do so many cool things in Smalltalk. For example, when you have a more concrete case of what you are looking for you can build something with method wrappers, or override DNU :-) to do your thing …
>

Sure. I think I deserve it. That's what you get if you ask questions about half baked thoughts :)

thanks,

Norbert