groovy
  1. groovy
  2. GROOVY-5426

ObjectRange.iterator() is reliant on size()

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.8.6
    • Fix Version/s: None
    • Component/s: groovy-jdk
    • Labels:
      None
    • Number of attachments :
      0

      Description

      Currently the ObjectRange iterator is reliant on the size of the range.

      If the range is made up of BigInteger or BigDecimal, would it be possible to safely change this to call increment or decrement on a current internal value until it reaches its destination?

      The problem is exhibited by:

      assert [] == (1.0G..2147483648.0G).iterator().take( 2 ).collect()
      

      Where I would expect [1, 2]

      The problem is that size (being an int) for this range is -2147483648

        Activity

        Hide
        Paul King added a comment -

        I suspect with the current implementation we should throw an exception when trying to create (or upon usage of) the range in your example. The current Range abstractions build upon java.util.List which has numerous methods taking or returning int parameters. We can obviously decide not to use the current abstractions but then passing ranges into methods designed for the existing collection api becomes a problem.

        Show
        Paul King added a comment - I suspect with the current implementation we should throw an exception when trying to create (or upon usage of) the range in your example. The current Range abstractions build upon java.util.List which has numerous methods taking or returning int parameters. We can obviously decide not to use the current abstractions but then passing ranges into methods designed for the existing collection api becomes a problem.
        Hide
        Tim Yates added a comment -

        Thinking about it, I agree, failing fast is probably for the best... If this sort of thing is required, then I guess a custom Range-like Iterator could be utilised

        Show
        Tim Yates added a comment - Thinking about it, I agree, failing fast is probably for the best... If this sort of thing is required, then I guess a custom Range-like Iterator could be utilised

          People

          • Assignee:
            Unassigned
            Reporter:
            Tim Yates
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: