-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Stream
counterparts to ReflectionSupport
utility methods returning List
#2779
Comments
I understand the rationale and can see the desire for that, though I don't think it's a high priority to refactor the code base to go that route. But maybe it's worth it to add such variants to Let's see what the rest of the team thinks. |
I see it similarly. I wouldn't object a contribution that adds such variants but also don't see it as a high priority for the team. |
Team decision: We'd be okay with a contribution that adds |
Hi, since this issue hasn't been assigned to anyone yet, can i please have a look into it ? @marcphilipp /@sbrannen, so if I understand correctly, there are methods which are currently returning a list of Fields but we would want to return a Stream instead of the list to reduce the overhead ? Will it be possible to direct me to the sections where these changes might be needed. I am fairly new to contributing to open source so it would be great if you could pardon my questions if they seem too generic. |
@Attyuttam Sure, go for it! I would propose you start by implementing a |
Now that I've seen all of the proposed new names in #3084, I'm wondering if we should use @junit-team/junit-lambda, thoughts? |
I agree that the |
👍 |
I agree with the nomenclature proposal. I just changed them and the pull request is available 👍 |
Hi @Ndione24, I was actually suggesting that "stream" replace "find" in those methods. So, |
Hi @sbrannen, I just renamed the methods :) |
Stream
counterparts to ReflectionSupport
utility methods returning List
Methods like
ReflectionSupport.findField
currently return aList<Field>
.Under-the-hood, the utils typically use streams and then copy all the elements into a list to return.
Very often, users of
findfield()
only need to iterate once through the returned list of fields (in some of my implementations, I've called stream() or forEach() on the result). Storing the stream of fields in an intermediateList
is unnecessary buffering overhead in those cases.Deliverables
Stream<Field> findFieldsAsStream()
.List<Field> findFields()
to delegate to its equivalent streaming method and calltoList()
on the stream.Thoughts?
The text was updated successfully, but these errors were encountered: