[
https://issues.apache.org/jira/browse/GROOVY-10666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17580380#comment-17580380
]
Eric Milles commented on GROOVY-10666:
--------------------------------------
With regards to instruction coverage, it was noted above:
{quote}The downside is that the iterator and getAt paths must both be written
into the bytecode. The upside is that many, many iterable types and iterator
itself will be used efficiently.{quote}
{quote}This would only be a breaking change for a type that implements both
iterator() and getAt(int) in an incongruent manner. My gut says this is few if
any types.{quote}
Besides examples where we purposely implement incongruent getAt and iterator,
do you know of any real world examples? Yes, this was noted as a risk. But I
think the actual risk is low; but obviously non-zero...
> Implement multiple-assignment (aka destructuring) via getAt(IntRange) or
> iterator()
> -----------------------------------------------------------------------------------
>
> Key: GROOVY-10666
> URL: https://issues.apache.org/jira/browse/GROOVY-10666
> Project: Groovy
> Issue Type: Improvement
> Components: bytecode, groovy-jdk
> Reporter: Eric Milles
> Assignee: Eric Milles
> Priority: Minor
>
> Currently multiple-assignment is implemented using {{getAt(int)}}. For types
> that support {{getAt(IntRange)}} it may be more efficient to use that
> operation. For cases where {{getAt(int)}} is a terminal operation (aka
> streams) it may be the only way to go. Or maybe using one {{iterator()}}
> would be better overall.
> Consider the following:
> {code:groovy}
> Set<String> set = ['foo','bar','baz']
> def (foo, bar, baz) = set // inefficient; requires 3 iterators and 6 calls to
> next
> Stream<String> stream = ['foo','bar','baz'].stream()
> def (foo, bar, baz) = stream // not possible because `getAt(int)` is terminal
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
