finished41 vs 49 keystrokesand this only gets alot worse when you use classes, cause you have to write out the hole class path.

Besid this silly counting ^^What I wanted to explain to you is that refactoring is a big thing. And you can't do this with your approach. I also wanted to point out that you don't save any time with your code generation.

Part of the motivation for doing it in the first place is that I often find myself, adding, removing, and editing message types and this config file is an easier place to do this.

changing stuff == refactoring which is much easier when you do it in the IDE, i.e. you change the name of a parameteralso when you change a single attribut of an message type, you have to rebuild all your messages, which is a lot of time you would waste. Editing a java class in your IDE doesn't take 10sec.

ps: don't get me wrong, writing such tools by yourselfs is always a quite interesting thing to do, but in alot of cases it doesn't really is that usefull in the end. I don't want to bash your idea, but my problem with it is that you are just writing the classes in an own DSL which doesn't save you anything in the end(time, and characters to type)

changing stuff == refactoring which is much easier when you do it in the IDE, i.e. you change the name of a parameteralso when you change a single attribut of an message type, you have to rebuild all your messages, which is a lot of time you would waste. Editing a java class in your IDE doesn't take 10sec.

You bring up a good point. If I have an event type that is already in use in a number of places and I decide to change a parameter name (attackScore to damageDealt), make the change and run the code gen, then change it where it is used, or I could do the refactoring in the IDE, in which case the generated class and then change the config file to match. Altering generated code is generally considered a big no-no though.

Java is verbosity. To avoid verbosity you usually go to other programming languages, for instance Python.

This is one of the worst arguments..."If you don't like a piece of X, abandon X and use Y instead"

The world isn't that black and white. We can workaround problems instead of completely discarding X.

I prefer Java because of it's verbosity. Makes it easy to maintain even months after I stopped using the code, comparable to C++ or Python where you rather will gain more in rebuilding the whole thing.

Though I can't see why you would prefer Java over all other languages except as of it's verbosity. It's a nice language though it's not better than all other languages except if you consider verbosity a virtue.

I don't see how your proposed solution makes it better. The added abstraction layer of getters and enums will lead to increased code verbosity throughout the project, which is (IMHO) an even bigger problem than typing out all those classes by hand.

Maybe I'm mistaken, and you could enlighten us with a code sample.

Going from OP:

Quote

System.out.println("BOOM " + explosion.getFloat(STRENGTH));

Where the basic thing is to just do in this case enum STRENGHT instead of "strength".

Metaprogramming makes perfect sense. Your problem is a very common problem that all developers reach at some point of their careers, because it is impossible not to notice certain repetitive tasks that could be automated somehow.

The problem is, Java is a terrible tool for that. That's why there are so many "frameworks" around. The language itself doesn't offer an easy way of generating code.

Dynamic languages like Python and Ruby are also bad, because their "metaprogramming" happens at runtime, not compilation.

Lisp has allowed developers to do what you want to do for the last 50 years. No extra libraries or frameworks needed, just the language itself.

I'm all for code generation, but I'm not seeing the need in this case with any of the given examples unless you're attempt some meta-uber-engine thingy. Why not just classify types of events and use a data-driven model where the parameters are specified in a configuration file? Do whatever works, but codegen seems like overkill without some concrete examples to show what "the problem is".

LISP is a fantastic language and very worthwhile to learn. And I sincerely hope to never need to (directly) programming in it ever again.

finished41 vs 49 keystrokesand this only gets alot worse when you use classes, cause you have to write out the hole class path.

Hi,

Not wanting to derail the thread but wanting to know more on expanding from "pf" to public final. Is this an eclipse thing? if so which plugin do I need to install? Google search did not reveal anything to me.

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.

By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.

Lisp's an object lesson in what happens to great languages that lack great toolchains and ecosystems when combined with a community that denies either is a problem. Clojure's nice, but it doesn't really renew Lisp any more than Ruby revolutionized Smalltalk.

I see this has popped up again. Some good discussion here. I was using my Message set up as an example to ask about compile time code generation. Don't get too hung up on the particulars of this specific example and whether it is worth doing; it's of more interest for everyone to discuss it in general.

I am aware that LISP can do this but this is the Java Gaming forum so I was curious if anyone has done this in the context of Java.

I'm not sure how you can make this claim when what I have shown is so narrow ( essentially a list of different types of Event Messages). It is data driven, and I don't think that a bunch of Event Messages that have a common base type constitutes "too little composition over inheritance".

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org