search

libgdx / gdx-liftoff

A modern setup tool for libGDX Gradle projects
Apache License 2.0
524 stars 48 forks source link

If the main class is named as "Game" with the "Game" template than the class has cyclic dependency. #149

Closed SonicGDX closed 4 months ago

SonicGDX commented 6 months ago

It's a very minor bug but if the main class is the same name as what it is extending there will be a cyclic dependency error. Not sure if this would be feasible /justifiable to put the effort into preventing this since it is obvious how to solve it (just write the full path for the class that it extends) but just thought I'd report this anyway.

tommyettinger commented 6 months ago

It's a fair point... I'm not sure how it could be solved in Liftoff code itself, since the template that's selected would affect what main class names are allowed. I think using the name of any core libGDX class for the main class name is a bad idea, though. Just like I wouldn't name a class in my code after something that exists in the core JDK library, like Array, I mean, Queue, I mean, Vector, I mean... uh...

cartesian-plane commented 4 months ago

It's a fair point... I'm not sure how it could be solved in Liftoff code itself, since the template that's selected would affect what main class names are allowed. I think using the name of any core libGDX class for the main class name is a bad idea, though. Just like I wouldn't name a class in my code after something that exists in the core JDK library, like Array, I mean, Queue, I mean, Vector, I mean... uh...

I would like to make a more general fix for this, but I'm not sure if there is any way to read what Template is selected. Is that not possible, or am I missing something?

tommyettinger commented 4 months ago

I have an easy monstrosity of a fix in the latest commit. I took the listing of every type in the libGDX core from a file generated in its docs, type-search-index.js, did some minor preprocessing with find+replace, and got a massive HashSet out of it. This is checked in the validation step for the main class field, and it also does a similar check to the one used for validating packages. Now, names such as Game, Stage, Map, Path, Cell, and so on are all noted as duplicates and forbidden from being the main class name. Platform-specific names aren't really a concern here yet, because so few classes might collide in a launcher file.

Thanks for your work, @cartesian-plane ! I do think the code that's in the latest commit is more robust, even if the way I wrote it is a little crazy. However, if you and @SonicGDX hadn't brought my attention to this issue, it would probably still be sitting here, collecting dust.

I think this is resolved, though I'm not totally sure. Please comment here or reopen after the next release (1.12.1.8) if this isn't solved then!