cgruber
commented
10 years ago To bring code-blocks into this context, here's the comment from the other thread (with re-phrasing):
Greg kick was toying with an idea (and I expended it a bit) of emitting a sort of code-block, such that instead of building up code, you have code that looks a lot (structurally) like the code you're going to emit, using the block initializer jazz. Very much the way Spec/BDD frameworks do. Sort of like:
CompliationUnit block = new CompliationUnit("com.google.whatever") {{
add(new ClassBlock(EnumSet.of(PUBLIC, FINAL), "MyClass") {{
add(new MethodBlock(EnumSet.of(PUBLIC, STATIC), Void.class, "main") {{
// You can loop.
for (Foo foo : foos) {
// Short cut for quick-and-dirty simple statements.
addStatement("%s.out.println(\"Hello World\")", System.class);
}
// More complex statement chains.
identifierFor(System.class).dot("out").dot("println").invoke(literal("Hello World!"));
}});
}});
}};It's totally a straw man, but this approach results in code that in shape/indentation/layout strongly matches the resulting emitted code, lets us do all the right things with accumulating types so we can emit shortened versions, etc. Heck, it can reflectively validate stuff along the way.
It can also be composed.
ClassBlock[] blocks = new ClassBlock[someNumber]
for (int i = 0; i < someNumber; i++) {
blocks[i] = new ClassBlock(EnumSet.of(PUBLIC, FINAL), "MyClass" + i) {{
add(new MethodBlock(EnumSet.of(PUBLIC, STATIC), Void.class, "main") {{
identifierFor(System.class).dot("out").dot("println").invoke(literal("Hello World!"));
}});
}};
}
CompliationUnit block = new CompliationUnit("com.google.whatever") {{
addAll(asList(blocks));
}};There are some down-sides, and the names suck just now, but there are some handy aspects to it. I normally really like fluent interfaces, but in this case, I think it doesn't serve the readability.
JakeWharton
gk5885
swankjesse
This issue will serve as a working space for what a potential version 3.0 would look like with a new, more dynamic, and more powerful API.
High-Level Goals
Deferred Type Compression
Currently, type compression via imports requires knowledge of all types up before the body of the file. In practice, this usually requires an awkward two-pass approach where you determine the imports based on a pass of dynamic contents and then emit the body based on a second pass.
The goal of this is to always emit fully-qualified types from the API and rely on a post-compression phase for emitting imports.
There are multiple ways to approach this. A non-exhaustive list:
Code Block Objects
Objects which represents pieces of code lend themselves naturally to writing emission code in Java. The wins should hopefully be fairly obvious.
There is a potential for API explosion here to cover the diversity of the Java language. A potential also exists for adding an unacceptable amount of boilerplate to the API.