But the tool of mark is a ui tool so why would you want to get a tool to
define a rule in your case?
In the future if mark and camille come up with a better rewrite engine
then of course we will use it.
Le 30/8/15 18:31, Marcus Denker a écrit :
No, just plain old ParseTreeRewriter.. but integrating Mark’s tool
would be very nice as a next step.
On 30 Aug 2015, at 14:34, Peter Uhnák <i.uh...@gmail.com
<mailto:i.uh...@gmail.com>> wrote:
Is this based on Mark's Rewrite Tool?
On Sun, Aug 30, 2015 at 10:27 AM, Marcus Denker
<marcus.den...@inria.fr <mailto:marcus.den...@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
