--- Begin Message ---
I simply love the dynamic rewriting this is just too cool. We should
systematically use it.
I will continue to use it in any deprecation.
Now I have a simple question (You can explain it to me over lunch one of these
days).
I do not get why RBAST would not be a good representation for the compiler?
I would like to know what is the difference.
You mean that before going from BC to AST was difficult?
How opal performs it? It does not use the source of the method to recreate the
AST but he can do it from the BC?
Stef
>>
>
> But I like the “high level”: using a shared AST between the compiler and the
> tools *and* having a mapping BC -> AST -> Text.
>
> Of course I understand that the choice to use the RB AST for the compiler is
> not a “traditional” one.. but it turned out to work very well *and* it brings
> some amazing power, as we have now not only a mapping bc->text offset, but a
> mapping bc->AST, too. This e.g. (just a a simple example) makes the magic of
> the runtime transforming deprecations possible. See #transform on class
> Deprecation, the #sourceNodeExecuted:
>
> transform
> | node rewriteRule aMethod |
> self shouldTransform ifFalse: [ ^ self ].
> self rewriterClass ifNil:[ ^ self signal ].
> aMethod := self contextOfSender method.
> aMethod isDoIt ifTrue:[^ self]. "no need to transform doits"
> node := self contextOfSender sourceNodeExecuted.
> rewriteRule := self rewriterClass new
> replace: rule key with: rule value.
> (rewriteRule executeTree: node)
> ifFalse: [ ^ self ].
> node replaceWith: rewriteRule tree.
> Author
> useAuthor: 'AutoDeprecationRefactoring'
> during: [aMethod origin compile: aMethod ast formattedCode
> classified: aMethod protocol].
>
>
> Marcus
--- End Message ---
