But it can be integrated with Rewrite Tool ;), it���s not so easy for everyone to write down a rewrite rule from scratch.

Yes, I think that having transformation applied without re-styling will be a huge improvement. Because now there is an ���autofix��� button, but I don���t use it myself as it restyles all the method.

Uko

On 30 Aug 2015, at 16:02, Mark Rizun <mrizun@gmail.com> wrote:

As far as I'm concerned, it's not based on my tool.

30 ��������. 2015 3:34 ���� "Peter Uhn��k" <i.uhnak@gmail.com> ��������:
Is this based on Mark's Rewrite Tool?

On Sun, Aug 30, 2015 at 10:27 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,

Small experiment:

1) add this method to Object:

deprecated: anExplanationString rule: aRule
        | builder ast rewriteRule method |
        builder := RBCompositeRefactoryChange named: 'deprecation'.
        method := thisContext sender sender method.
        ast := method ast copy.
        rewriteRule := RBParseTreeRewriter new replace: aRule key with: aRule value.

        (rewriteRule executeTree: ast) ifTrue: [
         builder compile: rewriteRule tree formattedCode in: method methodClass classified: method protocol ].
        builder execute.

2) to see it in action, add it to #ifNotNilDo:  in UndefinedObject:

ifNotNilDo: aBlock
        "Please use #ifNotNil: instead"
        self
                deprecated: 'Please use #ifNotNil: instead'
                rule: '`@receiver ifNotNilDo: `@statements'->  '`@receiver ifNotNil: `@statements'.
        ^ self


���> open a browser and see how it fixes code magically.

The only problem is that it does a whole-method refactoring while it should only affect the node
that triggered the deprecation. Else there could be wrong transformations if the same selector
is used but only one of the implementations need to be rewritten, while if we are able to rewrite
the exact sender, we can do it fully automatically.

        Marcus