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