Deprecator

Hello Pharo users,

Camille

Ammonite is not that sezzy :)
May be
autoRepair
selfRepair :)

Stef

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

location: 'http://smalltalkhub.com/mc/CamilleTeruel/Deprecator/main'

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 Teruel wrote:

On 24 juil. 2014, at 17:05, stepharo <[hidden email]> wrote:

Camille

Ammonite is not that sezzy :)

Because it has tentacles? :-D

May be
autoRepair
selfRepair :)

Yes for example ;)

How about 'Reprecator'   because you are Rep(airing)(Dep)recations.

Stef

On 24/7/14 14:34, Camille Teruel wrote:

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

location: 'http://smalltalkhub.com/mc/CamilleTeruel/Deprecator/main'

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

Dale Henrichs wrote:

ohoh:)

  Deprair

  Deprecair

Deprecare = Depreca(tion), care (of)

  DeDeprecate

On Thu, Jul 24, 2014 at 9:11 AM, Ben Coman <[hidden email]> wrote:

Camille Teruel wrote:

On 24 juil. 2014, at 17:05, stepharo <[hidden email]> wrote:

Camille

Ammonite is not that sezzy :)

Because it has tentacles? :-D

May be
autoRepair
selfRepair :)

Yes for example ;)

How about 'Reprecator'   because you are Rep(airing)(Dep)recations.

Stef

On 24/7/14 14:34, Camille Teruel wrote:

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

location: 'http://smalltalkhub.com/mc/CamilleTeruel/Deprecator/main'

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 teruel wrote

I hope for comments

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...

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 - 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 :)

On 7 août 2014, at 16:32, Sean P. DeNigris <[hidden email]> 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.

> 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 :)

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?

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.
>