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. 
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
^ 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:
^ self replacementMethodArg1: 2 + 2 arg2: 1 + 1.
and the result is #replacement
The repo is on sSmalltalkHub:
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.

3 thoughts on “Deprecator

  1. strategesis says:

    I assume you can’t know which method would be invoked when a message is sent? If that’s true, don’t you have to bring up the deprecation dialog for every sending of the message globablly, even if that particular message send would be dispatched to a different method?

    And if that’s the case, wouldn’t having a global set of deprecated methods that the programmer could add to or remove from be both simpler, and also provide a better mental model of the actual semantics of message selector deprecation?

  2. You don’t deprecate a message but a method. Only messages that end up dispatched on a deprecated method bring up a debugger. In that debugger you can rewrite the method that sent the message according to the rewriting expression associated with that deprecated method. Nothing special happens if a message is dispatched on a non-deprecated method.

  3. strategesis says:

    Gotcha. Thanks for the clarification.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: