Annotation that supports writing constructor call expressions without the 'new'
keyword. Instead they can be written "Ruby-style" as a method call to a 'new'
method or "Python-style" by just omitting the keyword missing.
It allows you to write code snippets like this ("Python-style"):
@Newify([Tree,Leaf]) class MyTreeProcessor {
def myTree = Tree(Tree(Leaf("A"), Leaf("B")), Leaf("C"))
def process() { ... }
}
or this ("Ruby-style"):
@Newify() class MyTreeProcessor {
def myTree = Tree.new(Tree.new(Leaf.new("A"), Leaf.new("B")), Leaf.new("C"))
def process() { ... }
}
After the AST transformation, the following code is passed on for further compilation:
class MyTreeProcessor {
def myTree = new Tree(new Tree(new Leaf("A"), new Leaf("B")), new Leaf("C"))
def process() { ... }
}
The annotation can be used on a whole class as shown above or selectively on a particular
method, constructor or field.
The "Ruby-style" new conversions occur automatically unless the 'auto=false'
flag is given when using the annotation. You might do this if you create a new method
using meta programming.
The "Python-style" conversions require you to specify each class on which you want them
to apply. The transformation then works by matching the basename of the provided classes to any
similarly named instance method calls not specifically bound to an object, i.e. associated
with the 'this' object. In other words
Leaf("A") would be transformed to
new Leaf("A") but
x.Leaf("A") would not be touched.
An example showing how to use the annotation at different levels:
@Newify(auto=false, value=Foo)
class Main {
@Newify() // turn auto on for field
def field1 = java.math.BigInteger.new(42)
def field2, field3, field4
@Newify(Bar)
def process() {
field2 = Bar("my bar")
}
@Newify(Baz)
Main() {
field3 = Foo("my foo")
field4 = Baz("my baz")
}
}
The annotation is intended to be used sparingly; perhaps in DSL scenarios or when
using deeply nested structural types. In particular, there is no support for using
the facility with two similarly named classes from different packages at the same time.
Though it is OK to have different packages in different contexts. Also, there is
no support for turning "Ruby-style" conversions off at the method, constructor or
field level if already turned on at the class level.