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

andThen overloading is confusing #287

Closed
junchuanwang opened this issue Oct 13, 2020 · 4 comments
Closed

andThen overloading is confusing #287

junchuanwang opened this issue Oct 13, 2020 · 4 comments

Comments

@junchuanwang
Copy link
Contributor

junchuanwang commented Oct 13, 2020

We have two andThen function available. One takes a consumer and second takes a Task.
They have different semantics and behavior.

https://github.com/linkedin/parseq/wiki/User's-Guide#sequential-composition

A misuse case is that user might use the variant that takes a Consumer function to return the task and want that task to be run, because any object can be cast to void, so the compiler won't issue warning of the consumer function returns the task

Solution can be
(1) add a new interface, e.g. something like andThenTask
(2) add additional logic to see if the return value from the Consumer function is of Task type and execute it (this requires another overloading andThen to take a Function<T, Task>

Linked Issue:
#207

@aliciatang
Copy link

+1 andThen use be used to indicate order of execution.
And the fact that when it takes a Task but does not pass on the result from the previous task is unexpected.

@junchuanwang
Copy link
Contributor Author

junchuanwang commented Jan 28, 2021

#291 can be complementary solution to #287 and #207

@BrianPin
Copy link

Good on identifying the misuse. +1 for slight preference on the resolution (2)
But I feel there is a common understanding among what consumer means, so it can return a task sounds a bit not common and different, so I suggest never expect consumer return anything

@junchuanwang
Copy link
Contributor Author

junchuanwang commented Jan 29, 2021

option (2) is not viable: the Consumer and Function when they apply to the lambda function, they have same erased type. So the lambda function will find two ambiguous overloading.

A better options is to change the signature to
default Task<T> andThen(final String desc, final Function1<? super T, ?> function)
and
check the return valuke of the function call.

Why I changed my mind:
But same behavior is achievable using flatMap. So it is hard to say if want to run the task if the return type found to be a task, because the user got this confusion just because they probably not aware of FlatMap.

I think we should educate the users instead.

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

No branches or pull requests

3 participants