Why isn't this in java

Discussion in 'Spigot Plugin Development' started by Kyllian, Jun 7, 2017.

  1. Hey, I was coding and I was wondering why this isnt in java.

    Instead of this:
    Code (Text):
    if (args[0].equalsIgnoreCase("on") || args[0].equalsIgnoreCase("enable")) {
    just doing
    Code (Text):
    if (args[0].equalsIgnoreCase("on" || "enable")) {
     
  2. In fact, i have made a method in my Utils class

    Code (Text):
        public static Boolean compareOr(Object o,Object... array)
        {
            return Arrays.stream(array).anyMatch(temp -> temp.equals(o));
        }
       
    Feel free to get it
     
    • Agree Agree x 1
    • Useful Useful x 1
  3. Because that's a huge syntactical change for a small need.
     
    • Agree Agree x 1
  4. sothatsit

    Patron

    It isn't a thing because it would have to either execute the code twice (Which could lead to non-obvious results and innefficiencies) or save the value in a variable before comparing it, which is not ideal for situations where it does not need to be put in a variable.

    For example, consider the code:
    Code (Text):
    if(randString().equalsIgnoreCase("apple" || "banana")) { ... }
    If it expands this to two randString().equalsIgnoreCases then it will compare two random Strings to two different Strings, which is probably not the intended behaviour. Alternatively, expanding it to save it in a variable seems messy, but is what would have to be done.

    You could argue that it should just always make it into a variable, but that just isn't efficient. You could say that the compiler should be able to optimise it, but it wouldn't be an easy thing to optimise once it gets into function calls that may or may not return the same value, and then calling a function on that first retrieved value that may or may not change the value.

    It's just too complicated for such a small use case, and if it was expanded to cover more use cases the intended behaviour becomes even more vague.

    TLDR:
    Would likely lead to non-obvious results and code that is difficult for the compiler to optimise. The effort required to make it a full-fledged language feature does not seem like it would be worth the required time for it not to be a mess.
     
    • Informative Informative x 1
    • Useful Useful x 1