Hello Pharo users,
I'm pleased to announce the release of Deprecator. It's a prototype of a small tool that permits you to deprecate method by annotating them with a <deprecated: ...> pragma. This pragma takes a rewrite expression as argument that specifies how to rewrite the message send to the deprecated method. If such a deprecated method is executed, a warning is thrown and a debugger opens. This debugger has a little 'Rewrite' button that permits to rewrite the sending method according to the rewrite expression and then resume the execution with the new rewritten sending method :) The implementation is a proof-of-concept and is a bit hacky here and there, but it works. Example: You have a class C with a method that you deprecate. Its rewrite expression tells that if it's executed as the result of a message send of the form: <receiver> deprecatedMethodArg1: <arg1> arg2: <arg2>, this message send should be rewritten to: <receiver> replacementMethodArg1: <arg2> arg2: <arg1>. Note you can change the order of arguments or even the receiver. C>>deprecatedMethodArg1: o1 arg2: o2 <deprecated: '`@receiver replacementMethodArg1: `@arg2 arg2: `@arg1'> ^ #deprecated C>>replacementMethodArg1: o1 arg2: o2 ^ #replacement C>>senderMethod ^ self deprecatedMethodArg1: 1 + 1 arg2: 2 + 2. Then if you execute C new senderMethod, and then click on the "Rewrite" button of the debugger, then sending method is rewritten to: C>>senderMethod ^ self replacementMethodArg1: 2 + 2 arg2: 1 + 1. and the result is #replacement. The repo is on sSmalltalkHub: MCHttpRepository user: '' password: '' I hope for comments, feature suggestions, code reviews, contributors, etc :) BTW, if you have a better name for this project let me know! For example, I thought about Ammonite because it's an extinct animal (analogy with deprecated) and it fits the sea naming theme. Cheers, Camille
|
Camille
Ammonite is not that sezzy :) May be autoRepair selfRepair :) Stef On 24/7/14 14:34, Camille Teruel wrote:
Hello Pharo users, |
On 24 juil. 2014, at 17:05, stepharo <[hidden email]> wrote:
Because it has tentacles? :-D
Yes for example ;)
|
Camille Teruel wrote:
How about 'Reprecator' because you are Rep(airing)(Dep)recations.
|
On 24 juil. 2014, at 18:11, Ben Coman <[hidden email]> wrote:
This one is fun :)
|
In reply to this post by Ben Coman
ohoh:) Deprair Deprecair DeDeprecate On Thu, Jul 24, 2014 at 9:11 AM, Ben Coman <[hidden email]> wrote:
|
Dale Henrichs wrote:
Deprecare = Depreca(tion), care (of)
|
haha! On Thu, Jul 24, 2014 at 10:01 AM, Ben Coman <[hidden email]> wrote:
|
Administrator
|
In reply to this post by camille teruel
How do you activate it? I loaded into #40160, and copied your snippets from the post, but when I did "MyClass new senderMethod", no debugger came up...
Cheers,
Sean |
On 7 août 2014, at 16:15, Sean P. DeNigris <[hidden email]> wrote: camille teruel wroteI hope for comments Sorry, I did a few modifications that I didn't reported here. First, the pragma changed. Now it's <deprecatedIn: #versionSymbol replaceWith: 'rewriteString'>. Second, the syntax changed: the '`@' that were needed before (for the RBParseTreeRewriter) are gone. So each available metavariable are written directly: receiver, arg1, arg2, ... arg15. You need the latest version (8). So the example is now: C>>deprecatedMethodArg1: o1 arg2: o2 <deprecatedIn: #Pharo42 replaceWith: 'receiver replacementMethodArg1: arg2 arg2: arg1'> ^ #deprecated C>>replacementMethodArg1: o1 arg2: o2 ^ #replacement C>>senderMethod ^ self deprecatedMethodArg1: 1 + 1 arg2: 2 + 2. Then evaluating C new senderMethod should bring the following pre-debug window. Cheers, Camille
|
Administrator
|
In reply to this post by Sean P. DeNigris
Oh, okay. I guess from looking at the tests that the new pragma is <deprecatedIn:replaceWith:> Next problem ;)... I see that you've omitted the RB `@ syntax. While easier to type, I don't like that it's more magical - what is the list of string tokens that are meaningful? Also, now the following now fails to compile with an "Unbounded variable" error preferencesGeneralFolder <deprecatedIn: 'Pharo 3.0' replaceWith: 'StartupPreferencesLoader preferencesGeneralFolder'> But this capability is /very/ exciting!! Thanks :)
Cheers,
Sean |
On 7 août 2014, at 16:32, Sean P. DeNigris <[hidden email]> wrote: > Sean P. DeNigris wrote >> How do you activate it? > > Oh, okay. I guess from looking at the tests that the new pragma is > <deprecatedIn:replaceWith:> > > Next problem ;)... > > I see that you've omitted the RB `@ syntax. While easier to type, I don't > like that it's more magical - It's because I don't want users to have to know RB pattern syntax and also because I plan to not depend on the rewriter in future versions. > what is the list of string tokens that are > meaningful? The available metavariables are: receiver: the receiver expression of the sending message node arg1, ..., arg15: the arguments expression of the sending message node > Also, now the following now fails to compile with an "Unbounded > variable" error > preferencesGeneralFolder > <deprecatedIn: 'Pharo 3.0' replaceWith: 'StartupPreferencesLoader > preferencesGeneralFolder'> I look at it now :) > But this capability is /very/ exciting!! Thanks :) > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Deprecator-tp4769843p4772316.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > |
Administrator
|
Ah I see. RB is powerful and well-known. While easy to replace for simple cases, I wonder if you might be forced to either limit that power or reinvent the wheel... Why not just rely on RB, which was designed for this and battle hardened over many years?
Cheers,
Sean |
Sorry for delay, I was taken by some other business :)
I fixed the bug you reported: check new version. On 7 août 2014, at 16:42, Sean P. DeNigris <[hidden email]> wrote: > camille teruel wrote >> It's because I don't want users to have to know RB pattern syntax and also >> because I plan to not depend on the rewriter in future versions. > > Ah I see. RB is powerful and well-known. While easy to replace for simple > cases, I wonder if you might be forced to either limit that power or > reinvent the wheel... Why not just rely on RB, which was designed for this > and battle hardened over many years? There are some problems with RB rewriter in some cases. For example it's hard to rewrite the sender of one message inside a cascaded messages because it entails changing some surrounding nodes to be a correct transformation. There are other cases like that that don't do what one expects. I can have a look to fix these cases, but I'm afraid to break many tools relying on the current behavior of the rewriter :) But if I can succeed doing that, I can keep using RB rewriter of course. > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Deprecator-tp4769843p4772319.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > |
> There are some problems with RB rewriter in some cases. > For example it's hard to rewrite the sender of one message inside a cascaded messages because it entails changing some surrounding nodes to be a correct transformation. > There are other cases like that that don't do what one expects. > I can have a look to fix these cases, but I'm afraid to break many tools relying on the current behavior of the rewriter :) improve it and we will check the side effects :) > But if I can succeed doing that, I can keep using RB rewriter of course. > |
Free forum by Nabble | Edit this page |