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

Add CheckedConsumer[N] and CheckedFunction[N] and add wrapper methods to Unchecked #225

Open
lukaseder opened this issue Mar 21, 2016 · 8 comments

Comments

@lukaseder
Copy link
Member

See also: #214 (comment)

@bendem
Copy link

bendem commented Apr 25, 2016

Came here to say that. I just had to write

.map(envelopeAndPath -> envelopeAndPath.map2(Function1.from(Unchecked.function(Files::newInputStream))))

Expected to find a method allowing this instead:

.map(envelopeAndPath -> envelopeAndPath.map2(Unchecked.function1(Files::newInputStream)))

or even

.map(envelopeAndPath -> envelopeAndPath.map2Unchecked(Files::newInputStream))

@lukaseder
Copy link
Member Author

Thanks for the feedback, @bendem. This will definitely add value when implemented.

@patrox
Copy link
Contributor

patrox commented Dec 1, 2016

hi @lukaseder & @bendem, could you please have a look at the following PR and let me know if this is what you were after ?

#272

Please note though, that for now this has been done for arity of 1.

@lukaseder
Copy link
Member Author

Hmm, I'm having a look at this again. I'm not quite sure what's wrong with this, @bendem:

.map(envelopeAndPath -> envelopeAndPath.map2(Unchecked.function1(Files::newInputStream)))

Tuple2.map2(Function) should accept the Function returned from Unchecked.function(). There's no need (IMO) to wrap this in a Function1, no?

Thanks for your suggestion, @patrox. That might be along the lines of what's being discussed here, although I wonder if we cannot just overload the existing function() and consumer() static utility methods in Unchecked and Sneaky. As the Function[N] and Consumer[N] arguments have different arities, the overload resolution should be non-ambiguous, no?

Do note that this code is generated, just as a hint before you move on to suggest manual implementations for all degrees 😉

@patrox
Copy link
Contributor

patrox commented Dec 2, 2016

@lukaseder yep, I'm aware that other arity methods are generated, so that's why I created just one set for the single arity to show the general idea :)

@lukaseder
Copy link
Member Author

@patrox: OK, I see. So, before discussing PRs, let's discuss use-cases. How would you like to use this new feature?

@bendem
Copy link

bendem commented Dec 5, 2016

Yes, my specific problem was fixed by 91e719d. Before that you had to use jool's Function1.

@lukaseder
Copy link
Member Author

Oh, I see. Thanks for the feedback. I hadn't checked the dates...

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

No branches or pull requests

3 participants