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
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 <norbert@hartl.name> 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
Hi Norbert, You can do anObject setTraitComposition: aTraitComposition but only works for behavior objects 2013/8/22 Jorge Ressia <jorge.ressia@gmail.com>
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 <norbert@hartl.name> 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
Jorge, Am 22.08.2013 um 15:28 schrieb Jorge Ressia <jorge.ressia@gmail.com>:
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 <norbert@hartl.name> 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
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
Am 23.08.2013 um 09:34 schrieb Stéphane Ducasse <stephane.ducasse@inria.fr>:
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
On Aug 23, 2013, at 3:48 AM, Norbert Hartl <norbert@hartl.name> 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
Am 23.08.2013 um 15:44 schrieb Johan Fabry <jfabry@dcc.uchile.cl>:
On Aug 23, 2013, at 3:48 AM, Norbert Hartl <norbert@hartl.name> 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
On Aug 23, 2013, at 9:54 AM, Norbert Hartl <norbert@hartl.name> wrote:
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,
No problem, I knew you would be able to handle my annoying response :-) And the half-baked thoughts can turn out to be the most fun ones to consider :-) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
On Aug 22, 2013, at 3:23 PM, Norbert Hartl <norbert@hartl.name> 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
Am 22.08.2013 um 16:25 schrieb Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Aug 22, 2013, at 3:23 PM, Norbert Hartl <norbert@hartl.name> 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
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
El 22-08-2013, a las 14:12, Stéphane Ducasse <stephane.ducasse@inria.fr> 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. Or maybe any system like traits have not come with efficient enough IDE? Cheers, Jura
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 <juraj.kubelka@gmail.com> 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
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 <jfabry@dcc.uchile.cl> 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 <juraj.kubelka@gmail.com> 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
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 <juraj.kubelka@gmail.com> 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 <jfabry@dcc.uchile.cl> 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 <juraj.kubelka@gmail.com> 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
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
Am 22.08.2013 um 22:03 schrieb Juraj Kubelka <juraj.kubelka@gmail.com>:
El 22-08-2013, a las 14:12, Stéphane Ducasse <stephane.ducasse@inria.fr> 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
Am 22.08.2013 um 20:12 schrieb Stéphane Ducasse <stephane.ducasse@inria.fr>:
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
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 <norbert@hartl.name> 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
Am 22.08.2013 um 20:29 schrieb Johan Fabry <jfabry@dcc.uchile.cl>:
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 <norbert@hartl.name> 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
participants (6)
-
Johan Fabry -
Jorge Ressia -
Juraj Kubelka -
Norbert Hartl -
Sebastian Tleye -
Stéphane Ducasse