groovy

Support for two-parameter closures in collect{} find{} each{} and etc accepting "it" and its index

Details

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

Description

This would be extremely useful, much more consistent and smarter than implementations like eachWithIndex. Whenever the user provides a two parameter closure to any of those Iterable extension methods, this would mean that the first parameter is the current item and the second is its index. If the closure has one parameter (or none), the current item gets passed. In all other cases it should throw an exception. A simple and very productive convention.

This feature would be very easy to implement by checking the closure.parameterTypes.length. I know that 'cuz I have it implemented in my lib. I can provide a patch if this will help the feature to be implemented sooner.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Paul King added a comment -

The issue being that for maps (at least) the two parameter variants are already in use for key/value variants. There would be times for maps when you would want key/value and other times when you would want entry/index.

Show
Paul King added a comment - The issue being that for maps (at least) the two parameter variants are already in use for key/value variants. There would be times for maps when you would want key/value and other times when you would want entry/index.
Hide
Permalink
Nikita Y Volkov added a comment -

Maps do not implement Iterable AFAIK, so there's a pretty evident difference in behaviour, needs and application. If we consider this feature only for Iterable's, maps won't be an issue and this makes perfect sense to me.

Show
Nikita Y Volkov added a comment - Maps do not implement Iterable AFAIK, so there's a pretty evident difference in behaviour, needs and application. If we consider this feature only for Iterable 's, maps won't be an issue and this makes perfect sense to me.
Hide
Permalink
blackdrag blackdrag added a comment -

How is implementing Iterable and having an index related?

Show
blackdrag blackdrag added a comment - How is implementing Iterable and having an index related?
Hide
Permalink
Nikita Y Volkov added a comment -

It's not that iterables have index, it's that they specifically support iteration and generating an index is just a matter of adding a counter into the iteration body. In case of ArrayList it will serve as both the index of the item in a collection and a counter of the iteration, in case of a Set it will serve as just a counter. If one would want to get something similar from a map he could use map.entrySet(). Yes and I forgot about arrays - of course this feature should also work on arrays.

In my 2 year experience of programming in Groovy I came across a lot of situations when I needed an index inside collect for instance, so if you need a practical proof I can lookup in my code base.

One of the cool things I see in implementation of this feature is that it doesn't mess any existing functionality, and all this functionality comes at a cost of a tiniest overhead from a single self.parameterTypes.length test

Show
Nikita Y Volkov added a comment - It's not that iterables have index, it's that they specifically support iteration and generating an index is just a matter of adding a counter into the iteration body. In case of ArrayList it will serve as both the index of the item in a collection and a counter of the iteration, in case of a Set it will serve as just a counter. If one would want to get something similar from a map he could use map.entrySet() . Yes and I forgot about arrays - of course this feature should also work on arrays. In my 2 year experience of programming in Groovy I came across a lot of situations when I needed an index inside collect for instance, so if you need a practical proof I can lookup in my code base. One of the cool things I see in implementation of this feature is that it doesn't mess any existing functionality, and all this functionality comes at a cost of a tiniest overhead from a single self.parameterTypes.length test

People

  • Assignee:
    Unassigned
    Reporter:
    Nikita Y Volkov
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: