21–27 of 27 posts
Have you considered an approach based on annotations and multi-line strings? I'm not sure string constants are valid targets for annotations but maybe that could be added to the language?
@Language(name="Javascript")
"""
function callBark(aBarker) {
aBarker.bark();
}
"""Thank you for making this. Have you considered an approach based on annotations and multi-line strings? I'm not sure string constants are valid targets for annotations but maybe that could be added to the language? @Language(name="Javascript") """ function callBark(aBarker) { aBarker.bark(); } """
Yes, Manifold already supports Java 15 multi-line strings (aka text blocks) like this:
var myValue = """
[>.jsEarlier quoted context omitted.
> What happens when this generated code has a bug? That's a bug in the generator and should be treated as such. Patch or throw out the generator. It's not sustainable to review and patch "generated code", because then it's just "code". The only reason I need code-on-disk is if I need to generate bindings into multiple languages.
But looking at the generated code, in the specific context where it was produced, is possibly a key step to understanding the bug in the generator. How else are you going to understand how to patch it, or whether the it's bad enough that you have to "throw out the generator" (if you can afford to do that)?
I'd drive a car to work to save time. If I have to get out and push the car instead, that's happening no more than once. I ditch the car, because it no longer saves me time. Getting out and pushing the car is not going to become part of my commute, and I'm not going to evaluate future cars on how easy they are to push.
You can afford to throw out the generator because it doesn't claim to give you new functionality. It just cuts down on boilerplate. If it can't do that properly, write the boilerplate.
Except it is not really embedded in Java, only in comments. I sincerely hope this dies a quick death. Java with its jars and infrastructure already makes it plenty convenient to work with resources without them having to be in your face when you are editing the file. Good IDE lets you move between the resource file and the code with a single click.
Java comments are Java. Embedding = in Java source, which requires some kind of delimiter, so the author conveniently repurposed multiline comments for that which is fine. Also, if you read the post, it clearly states you embed fragments in either comments or strings, if the fragments is a declaration vs a value.
> I sincerely hope this dies a quick death
Why the hostility? If you have something constructive to offer, great, otherwise this is the kind of comment that gives HN a bad rep.
Except it is not really embedded in Java, only in comments. I sincerely hope this dies a quick death. Java with its jars and infrastructure already makes it plenty convenient to work with resources without them having to be in your face when you are editing the file. Good IDE lets you move between the resource file and the code with a single click.
Java comments are Java. Embedding = in Java source, which requires some kind of delimiter, so the author conveniently repurposed multiline comments for that which is fine. Also, if you read the post, it clearly states you embed fragments in either comments or strings, if the fragments is a declaration vs a value.
> I sincerely hope this dies a quick death.
Why the hostility? If you have something constructive to offer, great, otherwise this is the kind of comment that gives HN a bad rep.
I'm curious how this works under the hood, looks like it's added as an annotation processor, and the DSL is embedded in specially formatted comments, but not in annotations. This implies to me the annotation processor is processing the comments in a source file? I did not know annotation processors could do this! Also implies comments carry through to the compiled .class files which I did not think they did either (r…
Hi, you can blame me for this. It's a Java compiler plugin[1], which is similar to an annotation processor, but can hook into the compiler at a much earlier stage, which allows it to contribute to all phases of the compiler, including the Parser phase. The Manifold plugin takes full advantage of this, hence its ability to analyze comments, contribute to bytecode generation, etc. [1] https://docs.oracle.com/javase/8/d…