search

stephenh / dtonator

code generator for creating DTOs and mapping to domain objects
Other
14 stars 5 forks source link

[Suggestion] Use Third Party Parser to Build Dto Classes #8

Closed pbtura closed 7 years ago

pbtura commented 7 years ago

While I was working on another issue, I happened to run across the javaparser library (https://github.com/javaparser/javaparser). This library seems ideal both for parsing the structure of the domain classes and for building the corresponding DTOs. What do you think of using this library (or something similar) as a replacement for the string interpolation currently being handled by joist?

stephenh commented 7 years ago

For generating code, I think the joist library is a pretty great sweet spot between the extremes of either pure-StringBuilder/string building (very tedious, hard to get indentation right, imports right, etc.) and pure-AST building (also very tedious because the AST for even a very small expression like if (a && b == whatever) is very verbose to create, e.g. new BinaryExp(new LocalVar("a"), new LocalVar("b") or whatever it would be).

I've seen projects that use both extremes, pure-strings and pure-ASTs, and I think joist's some-structure (class/method declarations) + some-strings (method implementations) is actually a good balance.

For parsing the incoming domain objects, it depends; just parsing the AST is typically not enough, e.g. the types would also need to be resolved, e.g. does the AST of private Foo foo = new Foo() refer to which Foo? One that is imported, or in the same package? This seems trivial, but I think has more nuances that is expected. So, in that regard, using reflection to get the incoming domain object information is actually very convenient and hard to see how having the AST would make things better.

The only case I could see it helping would be if the domain objects and to-be-generated-DTOs existed within the same project, and you wanted to somehow generate the DTOs w/dtonator before the domain object .class files existed. You can't use dtonator in this sort of setup currently, e.g. you have to have a three step: 1) compile domain objects, 2) run dtonator using .class files, 3) compile DTOs.

It would be nice to support running domain objects+dtonator in a single cycle, e.g. via an annotation processor, but even then the annotation processor environment provides reflection-ish type information vs. trying to reinvent/redo that from low-level ASTs.