Skip to content
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

1.x: scan with an initial factory callback #3959

Closed
wants to merge 2 commits into from

Conversation

akarnokd
Copy link
Member

@akarnokd akarnokd commented May 21, 2016

This PR adds an overload to scan which allows specifying an initial value factory. The initial value factory is invoked for each incoming Subscriber individually and provides a non-shared starting point for the scan operation.

I propose the scan(Func2 accumulator, Func0 initialFactory) parameter order because some Java 8+ compilers can't properly disambiguate with scan(R initialValue, Func2 accumulator), thinking that R can be made Func0.

Related: #3667

@abersnaze
Copy link
Contributor

Why add the overload if it can be done with defer and scan then?

@akarnokd
Copy link
Member Author

Yep, it can be done. A decision has to be made if this convenience should make it into the library or not, and notify @NiteshKant the outcome in #3667.

@davidmoten
Copy link
Collaborator

I'd like to see this overload in, thanks.

@zsxwing
Copy link
Member

zsxwing commented May 31, 2016

I'm not strong against adding it but not like the idea of the new parameter order. I would give +1 if giving it a better name instead of changing the parameter order. By the way, there is already a OperatorScan(Func0<R> initialValueFactory, Func2<R, ? super T, R> accumulator) for this overload so you don't need to use defer.

Probably @benjchristensen should take a look since you removed it before.

@benjchristensen
Copy link
Member

It was removed due to ambiguity as shown in #1881 (comment)

As long as that issue is not recreated, I have nothing against the functionality pursued here. I too don't like solving the overload ambiguity by moving parameter order around. But there is no good solution, it's either that or a new name.

@akarnokd
Copy link
Member Author

As an alternative, I suggest extending scan's javadoc with the example of the defer trick.

@akarnokd
Copy link
Member Author

The argument order bothers me as well. I'll close this and post a javadoc update instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants