Review of the chapter about AST transformations (GINA2)
Join the DZone community and get the full member experience.Join For Free
AST Transformations or compile-time metaprogramming is one of the coolest features of Groovy. I’m really excited about it as I didn’t see similar technologies in other mainstream languages. Sure we’ve been able to use macros in Lisp for decades but as a pragmatic person I’m more willing to play with technologies that I can use at my work and Groovy (and its AST transformations) is one of them.
First of all, some bad news. It isn’t easy to find a good manual about AST transformations. There are a few blog entries here and there and some documentation on official site but they don’t give you (at least, they didn’t give me) the whole picture. It led me to a decision to buy the second edition of Groovy in Action book. The final version hasn’t been released yet but the one you can buy right now has two most interesting chapters covering AST transformations and GPars.
The chapter about AST transformations is written by Hamlet D’Arcy who, I think, knows more about this topic than anybody else in Groovy community. The chapter comprises two parts:
- Brief review of existing AST transformations
- Tutorial describing how to write your own transformations
The first part is just a reference of all existing
transformations including all their parameters etc. The only thing it’d
be great to add is more examples. Such transformations as
@ToString are trivial and everybody knows where to use them. But
@ConditionalInterrupt are a different story. Though it is clear what they do it would be great to see more real-life examples of using them.
The second part of the chapter is more interesting. It covers such topics as writing local and global transformations, using visitors, testing and the limitations we have in Groovy when we use compile-time metaprogramming. Just read it through and you will have a good understanding of what should be done to make all the pieces work together. Though there is a lot of really valuable information in this part of the chapter it would be great to make some things clearer:
It was a right decision not to spend a half of the chapter describing
what AST is and how modern compilers work. The book isn’t about
compilers, it’s about Groovy. However, it’d be nice to see more
information about all the phases of Groovy compiler (not just a sentence
per phase). For instance, if you want to write a transformation adding a
‘before’ aspect to your class which phase will you choose and why:
CONVERSION, SEMANTIC_ANALYSIS, CANONICALIZATION, INSTRUCTION_SELECTION?
Sure, you can experiment using ‘Inspect AST’ in Groovy console, but
having a few paragraphs per phase in the book describing what Groovy
compiler adds to AST in each phase would be very nice too.
The second thing I didn’t get is guard clauses:
if (!astNodes || !astNodes) return
if (!(astNodes instanceof AnnotationNode)) return
if (astNodes.classNode?.name != Main.class.name) return
if (!(astNodes instanceof MethodNode)) return
I have no idea why I have to write them. If my annotation can be applied only to a method why should I perform all these checks? Just in case if there is a bug in Groovy compiler? It is not clear for me. If somebody knows the answer, please, let me know.
Also, there are a few mistypes in code samples, but the book is in early access. So I’m sure everything will be fixed in the final version.
Must have on a shelf of every Groovy developer
In spite of my criticism the whole book and the chapter about compile-time metaprogramming are really great. It’ll give you a good knowledge base and you will be able to start using compile-time metaprogramming right away. I’ve already written a bunch of transformations and I’m not going to stop! I can’t find any better way to express how I feel than this video:
Being so excited about all the compile-time metaprogramming stuff I’ve decided to write a few blog posts showing how to write an AST transformation and how powerful this technology is.
Opinions expressed by DZone contributors are their own.