August 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] RB API

by Sean P. DeNigris

Lukas Renggli wrote: > > Note that the classes contain actually excellent documentation. > Do you have any particular one in mind? I traced OB's execution to RBStringReplaceRule and then looked up the hierarchy finding basic few-sentence descriptions, but nothing in-depth about how to search and replace. Lukas Renggli wrote: > > Actually you can do it with a few clicks: Select #deprecated:, click > on "Refactor method > Add parameter" and follow the instructions. > Notice I asked about the API, not about the OB GUI. I needed to programmatically change each one depending on the sender's timeStamp and the collections of what was deprecated in which version. Also, there are already methods in the system with the name I'm changing to, so OB just mentions that and fails. Let me ask maybe a better question - how would you do the following programmatically? For each method that sends #deprecated: (except for certain excluded ones) change the send to #deprecated:on:in: where the second argument is the calling method's timeStamp and the third is 'Pharo1.3' or 'Pharo1.4' depending on which pre-made list it appears on. Cheers, Sean -- View this message in context: http://forum.world.st/RB-API-tp3781019p3781179.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 31, 2011

Re: [Pharo-project] RB API

by StÃ©phane Ducasse

I would love to have a real and nice documentation/tutorial because this is a great tool. Stef On Aug 31, 2011, at 4:17 PM, Lukas Renggli wrote: >> Is there any documentation on using AST & RB? > > http://www.refactory.com/RefactoringBrowser/index.html > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91.9246&rep=rep1&t… > >> I didn't find anything enlightening via google, the tests, or the >> class/method comments. > > Note that the classes contain actually excellent documentation. > >> In trying to replace all calls to #deprecate: and >> #deprecate:in: to #deprecate:on:in: (Issue 4718), it took me hours to step >> through OB's refactoring and learn the syntax. >> >> In case anyone else can benefit, I eventually ended up with: >> RBParseTreeRewriter new >> replace: '``@object deprecated: ``@arg1 ' >> with: '``@object deprecated: ``@arg1 on:(''', dateString, ''') >> in:(''Pharo', versionNumber asString, ''')'. > > Actually you can do it with a few clicks: Select #deprecated:, click > on "Refactor method > Add parameter" and follow the instructions. > > The rewrite engine takes a while to master. It is the infrastructure > that runs most of the refactorings and it is typically not necessary > for basic refactorings like this one. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Aug. 31, 2011

Re: [Pharo-project] RB API

by Lukas Renggli

> Is there any documentation on using AST & RB? http://www.refactory.com/RefactoringBrowser/index.html http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91.9246&rep=rep1&t… > I didn't find anything enlightening via google, the tests, or the > class/method comments. Note that the classes contain actually excellent documentation. > In trying to replace all calls to #deprecate: and > #deprecate:in: to #deprecate:on:in: (Issue 4718), it took me hours to step > through OB's refactoring and learn the syntax. > > In case anyone else can benefit, I eventually ended up with: > Â Â Â Â RBParseTreeRewriter new > Â Â Â Â Â Â Â Â replace: '``@object deprecated: ``@arg1 ' > Â Â Â Â Â Â Â Â with: '``@object deprecated: ``@arg1 on:(''', dateString, Â ''') > in:(''Pharo', versionNumber asString, ''')'. Actually you can do it with a few clicks: Select #deprecated:, click on "Refactor method > Add parameter" and follow the instructions. The rewrite engine takes a while to master. It is the infrastructure that runs most of the refactorings and it is typically not necessary for basic refactorings like this one. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 31, 2011

Re: [Pharo-project] RB API

by Igor Stasenko

isn't it should be deprecare[d] ... instead of deprecate... (i.e. names should be with 'd' at the end) ? On 31 August 2011 15:48, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Is there any documentation on using AST & RB? > > I didn't find anything enlightening via google, the tests, or the > class/method comments. In trying to replace all calls to #deprecate: and > #deprecate:in: to #deprecate:on:in: (Issue 4718), it took me hours to step > through OB's refactoring and learn the syntax. > > In case anyone else can benefit, I eventually ended up with: > Â Â Â Â RBParseTreeRewriter new > Â Â Â Â Â Â Â Â replace: '``@object deprecated: ``@arg1 ' > Â Â Â Â Â Â Â Â with: '``@object deprecated: ``@arg1 on:(''', dateString, Â ''') > in:(''Pharo', versionNumber asString, ''')'. > > Sean > > -- > View this message in context: http://forum.world.st/RB-API-tp3781019p3781019.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko AKA sig.

Aug. 31, 2011

[Pharo-project] #deprecate: & #deprecate:in: will be deprecated in 1.4

by Sean P. DeNigris

http://code.google.com/p/pharo/issues/detail?id=4718 I put a fix in the inbox that updates all existing calls to use #deprecate:on:in: -- View this message in context: http://forum.world.st/deprecate-deprecate-in-will-be-deprecated-in-1-4-tp37… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 31, 2011

[Pharo-project] RB API

by Sean P. DeNigris

Is there any documentation on using AST & RB? I didn't find anything enlightening via google, the tests, or the class/method comments. In trying to replace all calls to #deprecate: and #deprecate:in: to #deprecate:on:in: (Issue 4718), it took me hours to step through OB's refactoring and learn the syntax. In case anyone else can benefit, I eventually ended up with: RBParseTreeRewriter new replace: '``@object deprecated: ``@arg1 ' with: '``@object deprecated: ``@arg1 on:(''', dateString, ''') in:(''Pharo', versionNumber asString, ''')'. Sean -- View this message in context: http://forum.world.st/RB-API-tp3781019p3781019.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 31, 2011

Re: [Pharo-project] Symbol>value:

by StÃ©phane Ducasse

That discussion was in another focus. I think that people got confused. When I asked this silly question, I was in fact thinking about the implementation of Selector Namespace in the Smalltalk of david simmons. In fact a symbol (method invocation) was not just foo but namespace1.foo and put like that in the methoddic so you got '==" and "===" for is this symbol truly the same or the same and david implemented selector namespace without changing its vm. Now we are talking about something else. And mariano we could just identify method in Symbols that are - extensions - related to performish operation On Aug 31, 2011, at 3:12 PM, Nicolas Cellier wrote: > 2011/8/31 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> I arrive late to the discussion, but from my point of view, the correct >> solution is to create a subclass from Symbol, called Selector ;) and move >> all those methods there. There are lots of methods in Symbol which in fact >> only make sense when they are selectors. I know this change will never be >> done, but that's where those methods like #value: should be placed. >> I would love to see a clear division between Symbol and Selector. >> >> cheers >> > > Don't forget to read > http://comments.gmane.org/gmane.comp.lang.smalltalk.pharo.user/686 > again, and better twice, before deciding anything. > > Nicolas > >> On Tue, Aug 30, 2011 at 9:20 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> My suggestion is the following one: >>> we could add it because there is value: now I would not use it in >>> the core of the system. >>> I hope that one of these days we will be able to bootstrap and >>> identify a kernel and after that >>> we could tag a bit the methods in terms of layers. >>> >>> Stef >>> >>> On Aug 30, 2011, at 9:14 PM, StÃ©phane Ducasse wrote: >>> >>>> Indeed I would prefer just to have perform: and block value: >>>> >>>> Stef >>>> >>>> On Aug 30, 2011, at 8:34 PM, Lukas Renggli wrote: >>>> >>>>> Therefor I suggested to remove Symbol>>#value: the last time this was >>>>> brought up. >>>>> >>>>> If you keep it, besides all the variations of #value:... you also need >>>>> to consider #cull:, #cull:cull:, #cull:cull:cull:, >>>>> #valueWithArguments:, valueWithEnoughArguments:, >>>>> #valuWithPossibleArgs:, #valueWithPossibleArguments:; as well as >>>>> somebody needs to fix #numArgs (which is highly inconsistent with a >>>>> block that has the same behavior). >>>>> >>>>> Also for many asymmetric selectors the trick does not work (e.g. >>>>> #join:, #matches:, #includesSubString:, ...) because you need to turn >>>>> around the arguments. >>>>> >>>>> Aside from the above, evaluable selectors hamper readability: Back in >>>>> 2005 Magritte added #value: and #value:value: as method extensions. >>>>> You can go and read all the mails of people having troubles reading >>>>> the code. The benefit of writing a few characters less is really not >>>>> worth the trouble spent digesting the code. >>>>> >>>>> Lukas >>>>> >>>>> On 30 August 2011 20:09, Niko Schwarz <niko.schwarz(a)googlemail.com> >>>>> wrote: >>>>>> It's a question of consistency. Why support value:, but not >>>>>> value:value:? >>>>>> >>>>>> Niko >>>>>> >>>>>> On Tue, Aug 30, 2011 at 7:45 PM, Igor Stasenko <siguctua(a)gmail.com> >>>>>> wrote: >>>>>>> On 30 August 2011 18:02, Douglas Brebner >>>>>>> <squeaklists(a)fang.demon.co.uk> wrote: >>>>>>>> On 30/08/2011 13:30, Tudor Girba wrote: >>>>>>>> >>>>>>>> I proposed this some one or two years ago. I got shut down, but I >>>>>>>> still find >>>>>>>> it a good idea. >>>>>>>> >>>>>>>> And I even have a semantic reason: >>>>>>>> - A Block represents a piece of functionality that can be evaluated >>>>>>>> with >>>>>>>> some input >>>>>>>> - A Symbol often represents a selector which in turns represents a >>>>>>>> piece of >>>>>>>> functionality that can be evaluated with some input. >>>>>>>> >>>>>>>> I seem to recall there was discussion some time ago about splitting >>>>>>>> Selector >>>>>>>> functionality from Symbol. After all, there's no real reason that a >>>>>>>> selector >>>>>>>> has to be a Symbol. >>>>>>>> >>>>>>> >>>>>>> Selector is just a role to identify a method in method's dictionary. >>>>>>> It can be any object: if you look how VM does a lookup >>>>>>> there's nothing which limits a selectors to be the instances of >>>>>>> Symbol >>>>>>> (perhaps the only thing is printing a stack trace ;). >>>>>>> >>>>>>> What i mean that any object may be a selector: >>>>>>> >>>>>>> MyClass methodDict at: 1 put: someMethod. >>>>>>> >>>>>>> MyClass new perform: 1 >>>>>>> >>>>>>> should work. >>>>>>> >>>>>>> So, i don't see what you can gain by splitting functionality of >>>>>>> Selector from Symbol. Then you should put all selector-related >>>>>>> protocol to Object class. >>>>>>> And this even worse idea :) >>>>>>> >>>>>>> >>>>>>>> Also, some of the examples in this thread seem to be about terseness >>>>>>>> for >>>>>>>> terseness sake. >>>>>>>> >>>>>>> >>>>>>> Yeah. I have same impression. >>>>>>> But its cool :) >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Igor Stasenko AKA sig. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> http://scg.unibe.ch/staff/Schwarz >>>>>> twitter.com/nes1983 >>>>>> Tel: +41786126354 >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Lukas Renggli >>>>> www.lukas-renggli.ch >>>>> >>>> >>>> >>> >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >

Aug. 31, 2011

Re: [Pharo-project] The Keys to the Kingdom

by StÃ©phane Ducasse

Sean here is my idea (check the archive) We write tests and some of them we tag them <public api> or <help> and they should appear as that in the help of the package This way the programmer can even write comments in the test "I do that because this is like that and this has this effect" I tried to comment SOUP that way. Stef On Aug 31, 2011, at 1:22 PM, Sean P. DeNigris wrote: > IMHO, the biggest room for improvement is with Tests. What I loved about BDD > coming from Ruby is that it forces you to write tests from the perspective > of a user of the API. Often in Squeak/Pharo, I go to the tests and still > have no idea how to use the classes because the tests focus on > implementation details. > > -- > View this message in context: http://forum.world.st/The-Keys-to-the-Kingdom-tp3780556p3780712.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Aug. 31, 2011

Re: [Pharo-project] The Keys to the Kingdom

by StÃ©phane Ducasse

Yes yes yes I was thinking about it this morning.... I frustrated so much about the shout problem (because they were not a single comment that could help us to understand how it should be plugged) Alain is writing something and I will read it because I want to understand YYYYYYYEEEEEEESSSSSSS comments comments comments comments. Stef On Aug 31, 2011, at 1:28 PM, laurent laffont wrote: > Tomorrow is September 1st, summer holidays finished, I must continue COTDC, I must continue COTDC, I must continue COTDC, I ..... > > Laurent > > On Wed, Aug 31, 2011 at 1:18 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Yes, and I think these special thanks are addressed > to Stef and Laurent. > > Stef started with the idea not to include code that is > not documented - which was a little bit unrealistic > but lead to Laurents idea of a "Comment of the day" > game. > > The archive is your friend: > > http://lists.gforge.inria.fr/pipermail/pharo-project/2011-February/041356.h… > > Looks like we should continue to play this game ;) > > Bye > T. > -- > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! > Jetzt informieren: http://www.gmx.net/de/go/freephone > >

Aug. 31, 2011

Re: [Pharo-project] Symbol>value:

by Nicolas Cellier

2011/8/31 Mariano Martinez Peck <marianopeck(a)gmail.com>: > I arrive late to the discussion, but from my point of view, the correct > solution is to create a subclass from Symbol, called Selector ;)Â and move > all those methods there. There are lots of methods in Symbol which in fact > only make sense when they are selectors. I know this change will never be > done, but that's where those methods like #value: should be placed. > I would love to see a clear division between Symbol and Selector. > > cheers > Don't forget to read http://comments.gmane.org/gmane.comp.lang.smalltalk.pharo.user/686 again, and better twice, before deciding anything. Nicolas > On Tue, Aug 30, 2011 at 9:20 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> My suggestion is the following one: >> Â Â Â Â we could add it because there is value: now I would not use it in >> the core of the system. >> Â Â Â Â I hope that one of these days we will be able to bootstrap and >> identify a kernel and after that >> Â Â Â Â we could tag a bit the methods in terms of layers. >> >> Stef >> >> On Aug 30, 2011, at 9:14 PM, StÃ©phane Ducasse wrote: >> >> > Indeed I would prefer just to have perform: and block value: >> > >> > Stef >> > >> > On Aug 30, 2011, at 8:34 PM, Lukas Renggli wrote: >> > >> >> Therefor I suggested to remove Symbol>>#value: the last time this was >> >> brought up. >> >> >> >> If you keep it, besides all the variations of #value:... you also need >> >> to consider #cull:, #cull:cull:, #cull:cull:cull:, >> >> #valueWithArguments:, valueWithEnoughArguments:, >> >> #valuWithPossibleArgs:, #valueWithPossibleArguments:; as well as >> >> somebody needs to fix #numArgs (which is highly inconsistent with a >> >> block that has the same behavior). >> >> >> >> Also for many asymmetric selectors the trick does not work (e.g. >> >> #join:, #matches:, #includesSubString:, ...) because you need to turn >> >> around the arguments. >> >> >> >> Aside from the above, evaluable selectors hamper readability: Back in >> >> 2005 Magritte added #value: and #value:value: as method extensions. >> >> You can go and read all the mails of people having troubles reading >> >> the code. The benefit of writing a few characters less is really not >> >> worth the trouble spent digesting the code. >> >> >> >> Lukas >> >> >> >> On 30 August 2011 20:09, Niko Schwarz <niko.schwarz(a)googlemail.com> >> >> wrote: >> >>> It's a question of consistency. Why support value:, but not >> >>> value:value:? >> >>> >> >>> Niko >> >>> >> >>> On Tue, Aug 30, 2011 at 7:45 PM, Igor Stasenko <siguctua(a)gmail.com> >> >>> wrote: >> >>>> On 30 August 2011 18:02, Douglas Brebner >> >>>> <squeaklists(a)fang.demon.co.uk> wrote: >> >>>>> On 30/08/2011 13:30, Tudor Girba wrote: >> >>>>> >> >>>>> I proposed this some one or two years ago. I got shut down, but I >> >>>>> still find >> >>>>> it a good idea. >> >>>>> >> >>>>> And I even have a semantic reason: >> >>>>> - A Block represents a piece of functionality that can be evaluated >> >>>>> with >> >>>>> some input >> >>>>> - A Symbol often represents a selector which in turns represents a >> >>>>> piece of >> >>>>> functionality that can be evaluated with some input. >> >>>>> >> >>>>> I seem to recall there was discussion some time ago about splitting >> >>>>> Selector >> >>>>> functionality from Symbol. After all, there's no real reason that a >> >>>>> selector >> >>>>> has to be a Symbol. >> >>>>> >> >>>> >> >>>> Selector is just a role to identify a method in method's dictionary. >> >>>> It can be any object: if you look how VM does a lookup >> >>>> there's nothing which limits a selectors to be the instances of >> >>>> Symbol >> >>>> (perhaps the only thing is printing a stack trace ;). >> >>>> >> >>>> What i mean that any object may be a selector: >> >>>> >> >>>> MyClass methodDict at: 1 put: someMethod. >> >>>> >> >>>> MyClass new perform: 1 >> >>>> >> >>>> should work. >> >>>> >> >>>> So, i don't see what you can gain by splitting functionality of >> >>>> Selector from Symbol. Then you should put all selector-related >> >>>> protocol to Object class. >> >>>> And this even worse idea :) >> >>>> >> >>>> >> >>>>> Also, some of the examples in this thread seem to be about terseness >> >>>>> for >> >>>>> terseness sake. >> >>>>> >> >>>> >> >>>> Yeah. I have same impression. >> >>>> But its cool :) >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Best regards, >> >>>> Igor Stasenko AKA sig. >> >>>> >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> http://scg.unibe.ch/staff/Schwarz >> >>> twitter.com/nes1983 >> >>> Tel: +41786126354 >> >>> >> >>> >> >> >> >> >> >> >> >> -- >> >> Lukas Renggli >> >> www.lukas-renggli.ch >> >> >> > >> > >> >> > > > > -- > Mariano > http://marianopeck.wordpress.com > >

Aug. 31, 2011