groovy
  1. groovy
  2. GROOVY-1733

Let boolean operators (||, &&) evaluate to the value instead of the boolean equivalent

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: 3.0
    • Component/s: syntax
    • Labels:
      None
    • Number of attachments :
      0

      Description

      It would enable you to do some things a lot faster (eg. variable declaration) and would improve the current null-save navigation

      examples:

      def a = 0
      def b = null
      def c = "a string"
      def d = ""
      
      def val = a || c // c gets evalutated, because the boolean equivalent of a (0) is false
      
      assert a || b == null
      assert c || d == "a string"
      assert d || a == 0
      assert a || "another string" == "a string"
      assert d || "another string" == "another string"
      

      for null-save navigation:

      def val = aMap?.aProperty?.aSubProperty || "a default Value"
      

      or even for causal execution of code

      myobject.aMethodThatReturnsNullWhenItFails() || myobject.anotherMethod() 
      // myobject.anotherMethod gets only executed the result of the first call evalutes to false
      

      The current notation would not be affected in a negative way

      if(a || b){...} // would still work
      

      you would still have the possibility to get the boolean value by using !!

      eg.

      assert (0 || 15) instanceof Integer
      assert !!(0 || 15) instanceof Boolean
      

      The only language I know, which supports this currently is JavaScript

        Activity

        Hide
        Guillaume Laforge added a comment -

        Perhaps we could close this issue, as we have the Evlis operator.
        Isn't it enough?

        Show
        Guillaume Laforge added a comment - Perhaps we could close this issue, as we have the Evlis operator. Isn't it enough?
        Hide
        blackdrag blackdrag added a comment -

        while || can now be replaced by ?: there is also && and there is the possibility to use || and && in APIs. Or maybe make a new issue? Since this is not the focus of this issue?

        Show
        blackdrag blackdrag added a comment - while || can now be replaced by ?: there is also && and there is the possibility to use || and && in APIs. Or maybe make a new issue? Since this is not the focus of this issue?
        Hide
        Guillaume Laforge added a comment -

        Well, at least our comments echo the fact there's now Elvis.
        We could create a new issue, but we can stay with that one, it's okay.

        Show
        Guillaume Laforge added a comment - Well, at least our comments echo the fact there's now Elvis. We could create a new issue, but we can stay with that one, it's okay.
        Hide
        Robert Fischer added a comment -

        I'm not sure the Ruby-style impl makes sense in Groovy, since Groovy-truth is kinda a messed up concept. Getting an object back from || when it fails strikes me as odd. And since we've already got ?: which gives that behavior, do we really want to alias it as ||?

        That said, I can't come up with a use case where it's really the end of the world for || to return a false object. Just feels funny to me.

        Show
        Robert Fischer added a comment - I'm not sure the Ruby-style impl makes sense in Groovy, since Groovy-truth is kinda a messed up concept. Getting an object back from || when it fails strikes me as odd. And since we've already got ?: which gives that behavior, do we really want to alias it as ||? That said, I can't come up with a use case where it's really the end of the world for || to return a false object. Just feels funny to me.
        Hide
        Merlyn Albery-Speyer added a comment -

        Do we have any snippets of code that compellingly demonstrate the need for this improvement?

        Show
        Merlyn Albery-Speyer added a comment - Do we have any snippets of code that compellingly demonstrate the need for this improvement?
        Hide
        Guillaume Laforge added a comment -

        As the comments said, for one thing, we have Elvis.
        And also, from past discussions on the mailing-list, it would be a breaking change from a Java perspective that we'd return a value which may not be a boolean, which would break the existing contract in place.

        Show
        Guillaume Laforge added a comment - As the comments said, for one thing, we have Elvis. And also, from past discussions on the mailing-list, it would be a breaking change from a Java perspective that we'd return a value which may not be a boolean, which would break the existing contract in place.

          People

          • Assignee:
            Guillaume Laforge
            Reporter:
            Siegfried Puchbauer
          • Votes:
            3 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: