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

More formal support for Scala #213

Closed
wants to merge 1 commit into from

Conversation

mattrjacobs
Copy link
Contributor

  • This allows for type safety in statically-typed languages
    • This prevents dynamically-typed languages from hooking into rxjava-core.
      -- See Explore code generation for language adaptors #204 for details on code generation for dynamic languages
    • Added Scala implicits into rx.lang.scala.RxImplicits
    • Added tests of most methods on Observable using Scala functions
    • Fixed Scala Gradle/ScalaTest build

 - This allows for type safety in statically-typed languages
 - This prevents dynamically-typed languages from hooking into rxjava-core.
 -- See ReactiveX#204 for details on code generation for dynamic languages

 * Added Scala implicits into rx.lang.scala.RxImplicits
 * Added tests of most methods on Observable using Scala functions
 * Fixed Scala Gradle/ScalaTest build
@cloudbees-pull-request-builder

RxJava-pull-requests #56 FAILURE
Looks like there's a problem with this pull request

@benjchristensen
Copy link
Member

This pull request is for issue #208

@jmhofer
Copy link
Contributor

jmhofer commented Apr 11, 2013

The Scala implicits look good to me. Adding the ability to use observables the for-comprehension way is awesome.

Maybe it's better in the long run to use the "enrich my library" pattern and add explicit ".toRx" methods instead of all the automatic implicit conversions (see JavaConversions vs JavaConverters)? I'm not sure about that. Imho it's an argument of convenience vs explicitness. - However, as all this only concerns the Rx utility ActionX and FuncX classes I think I'd also prefer direct implicit conversions because the intent of those classes is very specific, and they match the Scala functions very naturally.

def map[B](f: A => B): Observable[B] = wrapped.map(f)
def flatMap[B](f: A => Observable[B]): Observable[B] = wrapped.mapMany(f)
def foreach(f: A => Unit): Unit = wrapped.forEach(f)
def withFilter(p: A => Boolean): WithFilter = new WithFilter(p)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this necessary, couldn't it just return wrapped.filter(p) here?

@mattrjacobs
Copy link
Contributor Author

@jmhofer I considered the .toRx approach as well, but in the end I agreed with your point about the scope of these implicits. Since we're only converting into rx.FuncX and rx.ActionX, it seems like it's hard to hit some unintended consequences.

The only thing holding this up is the work on #204, which I'm making good progress on.

@benjchristensen
Copy link
Member

Just checking in ... this is still on hold while waiting on #204.

Good progress has been made by @mattrjacobs but completion has been held up for a bit (higher priority work).

jihoonson pushed a commit to jihoonson/RxJava that referenced this pull request Mar 6, 2020
…eption is… (ReactiveX#213)

* ReactiveX#212 reactor.core.Exceptions$BubblingException thrown if exception is thrown in subscribe

* ReactiveX#35 Fix Codacity issues
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

Successfully merging this pull request may close these issues.

5 participants