Details

    • Type: Sub-task
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: core-libs
    • Labels:

      Description

      >> Constructs a loop that runs a given number of iterations.

      It looks a little bit unclear, because there is no 'number' arguments in method definition. I suppose it would be better to mention that number of iteration is specified by given method handle invocation result (first arg). Actually, it is mentioned in 'parameters' section, but it is a little bit unclear in description. This part of description is really clear in the countedLoop(MH, MH, MH, MH)

      >> The loop counter is an int initialized from the iterations handle evaluation result.

      This sentence differs from pseudocode, because loop counter in pseudcode is initialized to 0. It could lead to misunderstanding. Moreover if we are talking about initialization value it would be good to note that the counter is incremented (or decremented) per 1 after each loop step. This part of description is really clear in the countedLoop(MH, MH, MH, MH)

      >> The iterations handle must accept the same parameter types as init but return an int

      I suppose it would be good to mention that 'iterations' shouldn't be null, because we can't talk about 'null' return value. According to realization, iterations = null leads to message "java.lang.IllegalArgumentException: found non-effectively identical parameter type lists" which is not so easy to decode in terms of countedLoop.

      >> The counter is passed to the body function, so that must accept an initial int argument.

      The second part looks unclear. Is there typo?

      >> The result of the loop execution is the final value of the additional local state.

      'Additional state' is defined in 'init' definition (at the end of documentation). At this point it is hard to understand what does it mean. And maybe it would be better to change 'result of loop execution' to 'result of created method handle invocation' or something like this. There is small ambiguity (loop method vs loop result structure). This part of description is really clear in the countedLoop(MH, MH, MH, MH)

      >> The body handle must accept the same parameter types as well, preceded by an int parameter for the counter, and a parameter of the same type as init's result.

      It would be good to add information about body return type. According to MethodHandles.loop(...), pseudocode and realization, there is one more restriction: body handle should have the same return type as 'init'

      >> The iterations handle must accept the same parameter types as init but return an int.

      According to given 'lambdaman' example, 'iterations' could have no parameters.

      + It is hard to deduce resulting handle parameter list in the case of absent 'init' function. The situation is the same as in JDK-8150964 comment

        Attachments

        1. CountedLoopProposal1.java
          3 kB
        2. CountedLoopProposal10.java
          2 kB
        3. CountedLoopProposal11.java
          7 kB
        4. CountedLoopProposal12.java
          3 kB
        5. CountedLoopProposal14.java
          1 kB
        6. CountedLoopProposal2.java
          1 kB
        7. CountedLoopProposal3.java
          1 kB
        8. CountedLoopProposal4.java
          1 kB
        9. CountedLoopProposal5.java
          2 kB
        10. CountedLoopProposal6.java
          2 kB
        11. CountedLoopProposal7.java
          2 kB
        12. CountedLoopProposal8.java
          2 kB
        13. CountedLoopProposal9.java
          4 kB

          Issue Links

            Activity

              People

              • Assignee:
                mhaupt Michael Haupt
                Reporter:
                asolodkaya Anastasiya Solodkaya (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: