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 <[email protected]> wrote: > > As far as I'm concerned, it's not based on my tool. > > 30 серп. 2015 3:34 пп "Peter Uhnák" <[email protected] > <mailto:[email protected]>> пише: > Is this based on Mark's Rewrite Tool? > > On Sun, Aug 30, 2015 at 10:27 AM, Marcus Denker <[email protected] > <mailto:[email protected]>> 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 >
