Re: Minor breaking change of chop(Iterator, int...) method for Groovy 5

I think the change is good and the right one. Consistency of API will 
bring a much better benefit in the long run compared so the initial 
discomfort to adapt.

Regards,

Per

On 4/4/25 13:41, Paul King wrote:
> Hi folks,
>
> I am seeking feedback on making a breaking change for the DGM chop
> method (just for an Iterator parameter) for Groovy 5. This wouldn't
> change chop for any of the other aggregate types (collections and
> arrays).
>
> For our DGM methods on iterators, we have a bunch that are a little
> like stream intermediate operators which return iterators, and others
> which are more like terminal operators which return non-aggregate
> results or some kind of aggregate like a collection. The benefit of
> the ones which return iterators is that they are lazily evaluated (to
> vary degrees). You can chain a bunch of them together and intermediate
> calculations are done lazily, and intermediate collections aren't
> created unnecessarily, saving memory and time.
>
> Currently, chop is treated like a terminal operator (fully eager),
> returning a list of lists. I'd like to make this an iterator of lists
> (just when working on an iterator). This would make it align more
> closely with other operators (e.g. collate and others). I'd supply a
> bridge method with the existing signature, so code compiled with
> Groovy 4 and earlier using compile static would happily work without
> change.
>
> Is this really needed? Well, to some extent no. We can just call
> ".toIterator()" and continue chaining. There will just be one step
> that isn't as efficient as it could be.
>
> Is this the most efficient and lazy? Well, no, returning an iterator
> of iterators could be made more lazy.
>
> But the iterator of lists is the happy middle ground we have chosen
> for many other operators and that is what I'd like to move this to. We
> could always add a "chopLazy" or some such that return the iterator of
> iterators. And also consider collateLazy, etc.
>
> There is a PR here:
> https://github.com/apache/groovy/pull/2173
>
> The implications: folks using this method (we don't believe it is
> widely used) would need to add ".toList()" if they needed the eager
> behavior. Folks wanting the chaining behavior would no longer need to
> add ".iterator()".
>
> Breaking changes are always disruptive but inconsistent APIs are also
> troublesome. We are seeking feedback on whether folks would be greatly
> impacted/amenable to this change. It would be added as a breaking
> change in the release notes.
>
> Thoughts?
>
> Thanks, Paul.