Message-ID: <1092201511.2257.1429477369526.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_2256_1543983766.1429477369525" ------=_Part_2256_1543983766.1429477369525 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The @Newify transformation proposes two new ways of instantiatin= g classes. The first one is providing Ruby like approach to creating instan= ces with a new() class method:=20 =20
But it is also possible to follow the Python approach with omitting the = new keyword. Imagine the following tree creation:=20 =20
The creation of the tree is not very readable because of all those new k= eywords spread across the line. The Ruby approach wouldn't be more readable= , since a new() method call for creating each element is needed. But by usi= ng @Newify, we can improve our tree building slightly to make it easier on = the eye:=20 =20
You'll also notice that we just allowed Tree and Leaf to be newified= . By default, under the scope which is annotated, all instantiations a= re newified, but you can limit the reach by specifying the classes= you're interested in. Also, note that for our example, perhaps a Groovy bu= ilder may have been more appropriate, since its purpose is to indeed create= any kind of hierarchical / tree strucutre.=20
If we take another look at our coordinates example from a few sections e= arlier, using both @Immutable and @Newify can be interesting for creating a= path with a concise but type-safe manner:=20 =20
A closing remark here: since a Path(Coordinates coordinates) was gener= ated, we can use that constructor in a varargs way in Groovy, just= as if it had been defined as Path(Coordinates... coordinates).