August 2013 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Rw engine and Patterns for searching

by Gisela Decuzzi

Hi Camille! Thanks for the details about using the dot. I know that for this case is better matching an expression but it sounded strange at the begining the behavior inside the block despite of the ``@ I will take a look in the matching. Because like that we cannot say that we don't care if we have that piece of code and we should repeat the pattern with an or containing the block and without it. But I don't understand if the actual behavior is really a bug or it's a feature... 2013/8/21 Camille Teruel <camille.teruel(a)gmail.com> > Hello Gisela, > > On 21 aoÃ»t 2013, at 15:43, Gisela Decuzzi wrote: > > Hello, I'm trying to understand how to define a correct pattern and I'm > lost with the cases where I use a method pattern and the desired code is > inside a block. > In the case where we search (methods) with metavariables and the code is > inside a block. > > An Example: > > This pattern > `a: `aa `b: `bb > | `@temps | > ``@.Stats. > ``@.some size ``@.more. > ``@.Stats2. > > > Putting a dot after the @ means that you want to match statements. > So '``@.some size' cannot match: 'arg1 size'. > > Does not match with: > insideABlock: arg1 part2: arg2 > |temp1 temp3| > [arg1 size]. > temp1 := arg2 + 3. > ^arg2 > > > Then even if you remove the extra dots, the rule won't match the method > you give. > This is because this method has no statements matching '``@some size' > (even if it has a block that has a statement that can). > So here is a rule that can match your method: > `a: `aa `b: `bb > | `@temps | > `@.stms1. > [ `@rcv size ]. > `@.stms2. > > > After looking while I realize that is not matching with > part1: arg1 part2: arg2 > |temp1 temp2 temp3| > arg1 size. > temp1 := arg2 + 3. > ^arg2 > > > This one however can be matched by your rule (without the extra dots). > I think that you should try to parse expressions instead of full methods > (RBParseTreeSearcher>>#matches:do: instead > of RBParseTreeSearcher>>#matchesMethod:do:). > You could just try to match '`@rcv size': it would succeed in both methods. > > > Until I understand: > ``@.some size ``@.more. > This should mean: anything that sends the message size, doesn't matter if > we have something before or after, I think that this expression should > match both cases. > > But maybe I'm missunderstanding the patterns (again). > > > It should work like that (modulo bugs) > > - ` denotes a metavariable > - adding @ means you're looking for a list of elements > - ex: `receiver `@msg: `@arg matches every message > - adding a . means you're looking for a statement (or a list of > statement if you combine it with @) > - adding # means you're looking for a literal > - adding another ` means that the pattern will be searched recursively > in each subexpressions even if the top one already matched > > > - it sometimes leads to infinite loops, but I don't remember exactly > when > - ex: in 'foo bar bar' : > - if you search for '`rcv bar' you'll find one match ('foo bar > bar') > - if you search for '``rcv bar' you'll find two matches ('foo > bar' and 'foo bar bar'). > - and I think it's all > > > > Any help with this will be really welcome! > > > >

Aug. 23, 2013

Re: [Pharo-users] Trait composition on runtime

by Norbert Hartl

Am 22.08.2013 um 22:03 schrieb Juraj Kubelka <juraj.kubelka(a)gmail.com>: > > El 22-08-2013, a las 14:12, StÃ©phane Ducasse <stephane.ducasse(a)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

Aug. 22, 2013

Re: [Pharo-users] Trait composition on runtime

by Norbert Hartl

Am 22.08.2013 um 20:12 schrieb StÃ©phane Ducasse <stephane.ducasse(a)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

Aug. 22, 2013

Re: [Pharo-users] Trait composition on runtime

by Norbert Hartl

Am 22.08.2013 um 20:29 schrieb Johan Fabry <jfabry(a)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(a)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 > >

Aug. 22, 2013

Re: [Pharo-users] Trait composition on runtime

by Norbert Hartl

Jorge, Am 22.08.2013 um 15:28 schrieb Jorge Ressia <jorge.ressia(a)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(a)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

Aug. 22, 2013

Re: [Pharo-users] Trait composition on runtime

by Johan Fabry

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(a)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(a)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(a)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

Aug. 22, 2013

Re: [Pharo-users] Trait composition on runtime

by Juraj Kubelka

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(a)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(a)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 > >

Aug. 22, 2013

Re: [Pharo-users] Trait composition on runtime

by Johan Fabry

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(a)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

Aug. 22, 2013

Re: [Pharo-users] Trait composition on runtime

by Juraj Kubelka

El 22-08-2013, a las 14:12, StÃ©phane Ducasse <stephane.ducasse(a)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

Aug. 22, 2013

Re: [Pharo-users] Trait composition on runtime

by Johan Fabry

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(a)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

Aug. 22, 2013