Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.6
    • Fix Version/s: 1.6-rc-1, 1.5.8, 1.7-beta-1
    • Component/s: None
    • Labels:
      None
    • Testcase included:
      yes
    • Number of attachments :
      1

      Description

      GStrings show surprising behaviour when used as keys in collections or in comparisons. This lead to a lot of issues, e.g. (GROOVY-626, GROOVY-2332, GROOVY-2330, GROOVY-951, GROOVY-2660, GROOVY-1959). The situation is even worse with lazy evaluation of closures in GStrings (see attached script).

      So either

      Document that the user should

      • use GString#toString() instead of putting GString (as a key) into a collection, and
      • use GString#toString() instead of GString in comparisons with a String.

      Or

      Coerce arguments that are instanceof GString to String if the receiving parameter's type is not GString or a type derived from GString.

      I would prefer 1. over 2.

        Activity

        Hide
        blackdrag blackdrag added a comment -

        I am for documenting this, therefor I am changing the issue type to Improvement and reducing the priority. Automatic coercion is very very troublesome. We decided for the GString to be so different, because of the troubles we can not solve as they happen in java code. I prefer the user to fail fast with this, than somewhere in production code. So I am also not interested in a solution that works almost or that works from the Groovy side only. Either it works from both sides or we remain with what we have.

        Show
        blackdrag blackdrag added a comment - I am for documenting this, therefor I am changing the issue type to Improvement and reducing the priority. Automatic coercion is very very troublesome. We decided for the GString to be so different, because of the troubles we can not solve as they happen in java code. I prefer the user to fail fast with this, than somewhere in production code. So I am also not interested in a solution that works almost or that works from the Groovy side only. Either it works from both sides or we remain with what we have.
        Hide
        Guillaume Laforge added a comment -
        Show
        Guillaume Laforge added a comment - Documentation was added to the wiki: http://docs.codehaus.org/display/GROOVY/Strings+and+GString

          People

          • Assignee:
            Guillaume Laforge
            Reporter:
            Alexander Veit
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: