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

2.x - Add interfaces for Action3 through Action9 #4406

Closed
pakoito opened this Issue Aug 23, 2016 · 9 comments

Comments

Projects
None yet
3 participants
@pakoito

pakoito commented Aug 23, 2016

Although maybe not required for the core package or can be expressed in terms of FunctionN, extension libraries for utils like partial application will still need them. We also have a couple of Action3 and Action4 through the codebase.

If this proposal is accepted and If nobody else is willing to pick up the ticket, I can just PR them in in a tick.

@pakoito pakoito changed the title from 2.x - Add Action3 through Action9 to 2.x - Add interfaces for Action3 through Action9 Aug 23, 2016

@JakeWharton

This comment has been minimized.

Show comment
Hide comment
@JakeWharton

JakeWharton Aug 23, 2016

Member

They'd be called Consumer3 through Consumer9. Very hesitant about putting them in RxJava when there's no first-party usage though.

What's the downside of defining your own?

Member

JakeWharton commented Aug 23, 2016

They'd be called Consumer3 through Consumer9. Very hesitant about putting them in RxJava when there's no first-party usage though.

What's the downside of defining your own?

@pakoito

This comment has been minimized.

Show comment
Hide comment
@pakoito

pakoito Aug 23, 2016

None from the technical perspective today, but more for extensibility and future-proofing. Keeping separate interfaces per library while using the rest of RxJava as a backend for FRP concepts seems a bit off, specially in Java 6 where SMIs are not interchangeable.

I too would like to, in the future, suggest adding some of the functional extension packages into the project to have first-party support for chain composition helpers like partial application or fmap. While they're more geared towards functional than reactive they've proven to be useful for conciseness in absence of lambdas in Java 6 projects without retrolambda or kotlin.

pakoito commented Aug 23, 2016

None from the technical perspective today, but more for extensibility and future-proofing. Keeping separate interfaces per library while using the rest of RxJava as a backend for FRP concepts seems a bit off, specially in Java 6 where SMIs are not interchangeable.

I too would like to, in the future, suggest adding some of the functional extension packages into the project to have first-party support for chain composition helpers like partial application or fmap. While they're more geared towards functional than reactive they've proven to be useful for conciseness in absence of lambdas in Java 6 projects without retrolambda or kotlin.

@akarnokd

This comment has been minimized.

Show comment
Hide comment
@akarnokd

akarnokd Aug 23, 2016

Member

Such interfaces can live in any library and since we don't have any use for them in the core RxJava library, I deliberately didn't port them from 1.x. 👎

Member

akarnokd commented Aug 23, 2016

Such interfaces can live in any library and since we don't have any use for them in the core RxJava library, I deliberately didn't port them from 1.x. 👎

@pakoito

This comment has been minimized.

Show comment
Hide comment
@pakoito

pakoito Aug 23, 2016

I see you didn't also port Actions.java :(

While not part of the core they are definitely part of using RxJava as a tool, specially in Java 6 environments. Actions.empty(), Action conversors, Function to Action are tools necessary to avoid unnecessary duplication. They add to the ergonomics of large projects.

Making it almost mandatory to use a third party library or copypaste code across projects just to be able to represent many ui functions, compose them, and have empty Actions through the app is a big penalty for just a small price of 6 interfaces and one helper class that are easily portable.

pakoito commented Aug 23, 2016

I see you didn't also port Actions.java :(

While not part of the core they are definitely part of using RxJava as a tool, specially in Java 6 environments. Actions.empty(), Action conversors, Function to Action are tools necessary to avoid unnecessary duplication. They add to the ergonomics of large projects.

Making it almost mandatory to use a third party library or copypaste code across projects just to be able to represent many ui functions, compose them, and have empty Actions through the app is a big penalty for just a small price of 6 interfaces and one helper class that are easily portable.

@akarnokd

This comment has been minimized.

Show comment
Hide comment
@akarnokd

akarnokd Aug 23, 2016

Member

They add to the ergonomics of large projects.

Roll your own library with the classes and interfaces you need.

Making it almost mandatory to use a third party library or copypaste code across projects just to be able to represent many ui functions, compose them

RxJava has to keep focus on reactive and host only what it needs to accomplish that task. By this logic we would have to include the whole world. The converse is also problematic: why include the whole RxJava for just its functional interfaces (like IxJava which I'll switch to its own interfaces for 2.x).

Member

akarnokd commented Aug 23, 2016

They add to the ergonomics of large projects.

Roll your own library with the classes and interfaces you need.

Making it almost mandatory to use a third party library or copypaste code across projects just to be able to represent many ui functions, compose them

RxJava has to keep focus on reactive and host only what it needs to accomplish that task. By this logic we would have to include the whole world. The converse is also problematic: why include the whole RxJava for just its functional interfaces (like IxJava which I'll switch to its own interfaces for 2.x).

@pakoito

This comment has been minimized.

Show comment
Hide comment
@pakoito

pakoito Aug 23, 2016

I'm not asking to include the whole world, just 6 interfaces that already existed in 1.0 and were used in projects in prod and third party libraries, like your IxJava.

Not having a different set of interfaces that cannot be converted to one another, but rather a central point for all of them that all extension libs can use, and they do not need project-to-project convertors in Java 6 to compensate for lack of functional interfaces.

Extension libraries bank on RxJava being in the project because other functional backends like Javaslang, Reactor, or functionaljava are not available on Java 6 or well supported on Android. Previous attempts at unifying callbacks by using the same generic interfaces are non-existent or not widespread.

pakoito commented Aug 23, 2016

I'm not asking to include the whole world, just 6 interfaces that already existed in 1.0 and were used in projects in prod and third party libraries, like your IxJava.

Not having a different set of interfaces that cannot be converted to one another, but rather a central point for all of them that all extension libs can use, and they do not need project-to-project convertors in Java 6 to compensate for lack of functional interfaces.

Extension libraries bank on RxJava being in the project because other functional backends like Javaslang, Reactor, or functionaljava are not available on Java 6 or well supported on Android. Previous attempts at unifying callbacks by using the same generic interfaces are non-existent or not widespread.

@akarnokd

This comment has been minimized.

Show comment
Hide comment
@akarnokd

akarnokd Aug 23, 2016

Member

We are a reactive stream composition library and not a functional composition library. We can map twice if needed.

Having a separate library has its own benefits:

  • compact and focused,
  • any number of helper classes,
  • include in other libraries and projects independent of RxJava
  • separate lifecycle and versioning
  • can have bridge companion library to support RxJava's types
Member

akarnokd commented Aug 23, 2016

We are a reactive stream composition library and not a functional composition library. We can map twice if needed.

Having a separate library has its own benefits:

  • compact and focused,
  • any number of helper classes,
  • include in other libraries and projects independent of RxJava
  • separate lifecycle and versioning
  • can have bridge companion library to support RxJava's types
@pakoito

This comment has been minimized.

Show comment
Hide comment
@pakoito

pakoito Aug 23, 2016

The functional composition can be kept as separate libraries, and I do understand your concern of keeping RxJava focused on being reactive rather than functional. I will refrain from suggesting adding any of those to RxJava in the future.

That's not exclusive from having 6 interfaces for Actions that are already used by 1.X consumers. The cost is non-existent and they do not introduce any problems on overhead or maintenance, but they do add value for RxJava projects and extension libraries.

pakoito commented Aug 23, 2016

The functional composition can be kept as separate libraries, and I do understand your concern of keeping RxJava focused on being reactive rather than functional. I will refrain from suggesting adding any of those to RxJava in the future.

That's not exclusive from having 6 interfaces for Actions that are already used by 1.X consumers. The cost is non-existent and they do not introduce any problems on overhead or maintenance, but they do add value for RxJava projects and extension libraries.

@akarnokd

This comment has been minimized.

Show comment
Hide comment
@akarnokd

akarnokd Aug 24, 2016

Member

Closing this as out of scope for 2.x.

Member

akarnokd commented Aug 24, 2016

Closing this as out of scope for 2.x.

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