Ambigous logical precedence on Game.java file

[CatCode79]

trafficstars

At line 280 on com.interrupt.dungeoneer.game.Game class:

    // then look for internal files
    if(Gdx.app.getType() == ApplicationType.Desktop &&
            (directory.type() == Files.FileType.Classpath) || (directory.type() == Files.FileType.Internal)) {

the && takes precedence over the || operator. But, for me at least, it's not very clear if it's semantically correct. I think it is better to put round brackets, in the right place, to dispel any doubts.

[joshuaskelly]

There are parenthesis around the right hand side of the && operator. The line break might be tripping you up?

if(Gdx.app.getType() == ApplicationType.Desktop && (directory.type() == Files.FileType.Classpath) || (directory.type() == Files.FileType.Internal)) { ... }

[CatCode79]

Uhm, I don't think so. I'm using Intellij and it's easier, rather than here, to look at the parenthesis context.

The left side of && operator currently is: (directory.type() == Files.FileType.Classpath) || (directory.type() == Files.FileType.Internal) and not: (directory.type() == Files.FileType.Classpath || directory.type() == Files.FileType.Internal) without the round brackets next to the || operator.

I doubt that the latest line could be the right one, or at least it's what the line break suggests to me.

The current logic, if we were to make it explicit, is: if((Gdx.app.getType() == ApplicationType.Desktop && (directory.type() == Files.FileType.Classpath)) || (directory.type() == Files.FileType.Internal)) {

[joshuaskelly]

Yeah. I see what you mean now. 🤦‍♂️

[PythooonUser]

Has this caused issues in the past?

[CatCode79]

Personally I haven't had any problems so far. But I have not used the modding system, ie what the code seems to interest

You can simplify the problem by noting that the listDirectory method, which contains the offending if-check, is only called by the DungeonGenerator.getLevelFilesInDir method. This method calls listDirectory with the following meaningful lines of code: FileHandle gf = Game.getInternal(genFolder); if(gf.exists()) { for(FileHandle entry : Game.listDirectory(gf)) {

So, if the Game.getInternal is correct the directory is always an internal directory. In this case the if-check, with the current logic, can be simplified from: if ((Gdx.app.getType() == ApplicationType.Desktop && directory.type() == Files.FileType.Classpath) || directory.type() == Files.FileType.Internal) { to: if ((Gdx.app.getType() == ApplicationType.Desktop && false) || true) {

Instead the if-check with the || logic encapsulated can be simplified from if (Gdx.app.getType() == ApplicationType.Desktop && (directory.type() == Files.FileType.Classpath || directory.type() == Files.FileType.Internal)) { to: if (Gdx.app.getType() == ApplicationType.Desktop && (false || true)) {

This means that in typical current usage (the first one), i.e. calling listDirectory with an internal directory, the if-check is always false. From what I understand this prevents the search for mods more extensively inside others directories.

(I double checked but I may have missed a reasoning error).

[CatCode79]

Nope, I used wrong assumptions in my previous reasoning. I tested the two versions of if-check and they both don't run the body of the if.

Checking the truth values ​​of all three logical expressions they always give this result: if (true && false || false)

or if (true && (false || false)) for the if-check variant

for this reason we always have the same behavior and che if body, in my tests, was never performed.