I don't see a problem making a breaking change in a major version update. Thanks for the thorough explanation!
/Mattias Den fre 4 apr. 2025 kl 17:57 skrev Per Nyfelt <p...@alipsa.se>: > 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. >
