-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
New Scala Bindings #598
Merged
benjchristensen
merged 57 commits into
ReactiveX:master
from
Applied-Duality:RebaseLatestChanges
Dec 10, 2013
Merged
New Scala Bindings #598
benjchristensen
merged 57 commits into
ReactiveX:master
from
Applied-Duality:RebaseLatestChanges
Dec 10, 2013
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Added missing empty implementations for Observer methods.
Solution was to delete all class files. Why is there no build/clean?
Cleaned up overloads for Observer.
Fixed Scheduler constructor to map to correct scheduler type.
release notes details
…ld put in hyperlink ;-)
to Subject[T] extends Observable[T] with Observer[T]. This was a generalization in .NET that did not pan out and Subject is always used with [T,T]. Fought to get multicast to work. I really hate Java variance.
…ingFinalStageSam Conflicts: language-adaptors/rxjava-scala/src/examples/scala/rx/lang/scala/examples/RxScalaDemo.scala language-adaptors/rxjava-scala/src/main/scala/rx/lang/scala/Notification.scala language-adaptors/rxjava-scala/src/main/scala/rx/lang/scala/Observable.scala language-adaptors/rxjava-scala/src/test/scala/rx/lang/scala/ObservableTest.scala language-adaptors/rxjava-scala/src/test/scala/rx/lang/scala/subscriptions/SubscriptionTests.scala
RxJava-pull-requests #532 SUCCESS |
This was referenced Jan 2, 2014
rickbw
pushed a commit
to rickbw/RxJava
that referenced
this pull request
Jan 9, 2014
…nges New Scala Bindings
jihoonson
pushed a commit
to jihoonson/RxJava
that referenced
this pull request
Mar 6, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(copied from release notes)
RxScala Release Notes
This release of the RxScala bindings builds on the previous 0.15 release to make the Rx bindings for Scala
include all Rx types. In particular this release focuses on fleshing out the bindings for the
Subject
andScheduler
types, as well as aligning the constructor functions for
Observable
with those in the RxJava.Expect to see ongoing additions to make the Scala binding match the equivalent underlying Java API,
as well as minor changes in the existing API as we keep fine-tuning the experience on our way to a V1.0 release.
Observer
In this release we have made the
asJavaObserver
property inObservable[T]
as well the the factory method in thecompanion object that takes an
rx.Observer
private to the Scala bindings package, thus properly hiding irrelevantimplementation details from the user-facing API. The
Observer[T]
trait now looks like a clean, native Scala type:To create an instance of a specific
Observer
, sayObserver[SensorEvent]
in user code, you can create a new instanceof the
Observer
trait by implementing any of the methods that you care about:or you can use one of the overloads of the companion
Observer
object by passing in implementations of theonNext
,onError
oronCompleted
methods.Note that typically you do not need to create an
Observer
since all of the methods that accept anObserver[T]
(for instance
subscribe
) usually come with overloads that accept the individual methodsonNext
,onError
, andonCompleted
and will automatically create anObserver
for you under the covers.While technically it is a breaking change make the
asJavaObserver
property private, you should probably not havetouched
asJavaObserver
in the first place. If you really feel you need to access the underlyingrx.Observer
call
toJava
.Observable
Just like for
Observer
, theObservable
trait now also hides itsasJavaObservable
property and makes the constructorfunction in the companion object that takes an
rx.Observable
private (but leaves the companion object itself public).Again, while technically this is a breaking change, this should not have any influence on user code.
The major changes in
Observable
are wrt to the factory methods where too libral use of overloading of theapply
method hindered type inference and made Scala code look unnecessarily different than that in other language bindings.
All factory methods now have their own name corresponding to the Java and .NET operators
(plus overloads that take a
Scheduler
).def from[T](future: Future[T]): Observable[T]
,def from[T](iterable: Iterable[T]): Observable[T]
,def error[T](exception: Throwable): Observable[T]
,def empty[T]: Observable[T]
,toObservable: Observable[T]
onList[T]
.In the pre-release of this version, we expose both
apply
andcreate
for the mother of all creation functions.We would like to solicit feedback which of these two names is preferred
(or both, but there is a high probability that only one will be chosen).
def apply[T](subscribe: Observer[T]=>Subscription): Observable[T]
def create[T](subscribe: Observer[T] => Subscription): Observable[T]
Subject
The
Subject
trait now also hides the underlying JavaasJavaSubject: rx.subjects.Subject[_ >: T, _<: T]
and takes only a single invariant type parameter
T
. all existing implementations ofSubject
are parametrizedby a single type, and this reflects that reality.
For each kind of subject, there is a class with a private constructor and a companion object that you should use
to create a new kind of subject. The subjects that are available are:
AsyncSubject[T]()
,BehaviorSubject[T](value)
,Subject[T]()
,ReplaySubject[T]()
.The latter is still missing various overloads http://msdn.microsoft.com/en-us/library/hh211810(v=vs.103).aspx which
you can expect to appear once they are added to the underlying RxJava implementation.
Compared with release 0.15.1, the breaking changes in
Subject
for this release aremaking
asJavaSubject
private, and collapsing its type parameters, neither of these should cause trouble,and renaming
PublishSubject
toSubject
.Schedulers
The biggest breaking change compared to the 0.15.1 release is giving
Scheduler
the same structure as the other types.The trait itself remains unchanged, except that we made the underlying Java representation hidden as above.
as part of this reshuffling, the scheduler package has been renamed from
rx.lang.scala.concurrency
to
rx.lang.scala.schedulers
. There is a high probability that this package renaming will also happen in RxJava.In the previous release, you created schedulers by selecting them from the
Schedulers
object,as in
Schedulers.immediate
orSchedulers.newThread
where each would return an instance of theScheduler
trait.However, several of the scheduler implementations have additional methods, such as the
TestScheduler
,which already deviated from the pattern.
In this release, we changed this to make scheduler more like
Subject
and provide a family of schedulersthat you create using their factory function:
CurrentThreadScheduler()
,ExecutorScheduler(executor)
,ImmediateScheduler()
,NewThreadScheduler()
,ScheduledExecutorServiceScheduler(scheduledExecutorService)
,TestScheduler()
,ThreadPoolForComputationScheduler()
,ThreadPoolForIOScheduler()
.In the future we expect that this list will grow further with new schedulers as they are imported from .NET
(http://msdn.microsoft.com/en-us/library/system.reactive.concurrency(v=vs.103).aspx).
To make your code compile in the new release you will have to change all occurrences of
Schedulers.xxx
into
XxxScheduler()
, and importrx.lang.scala.schedulers
instead ofrx.lang.scala.schedulers
.Subscriptions
The
Subscription
trait in Scala now hasisUnsubscribed
as a member, effectively collapsing the oldSubscription
and
BooleanSubscription
, and the latter has been removed from the public surface. Pending a bug fix in RxJava,SerialSubscription
implements its ownisUnsubscribed
.To create a
Subscription
use one of the following factory methods:Subscription{...}
,Subscription()
,CompositeSubscription(subscriptions)
,MultipleAssignmentSubscription()
,SerialSubscription()
.In case you do feel tempted to call
new Subscription{...}
directly make sure you wire upisUnsubscribed
and
unsubscribe()
properly, but for all practical purposes you should just use one of the factory methods.Notifications
All underlying wrapped
Java
types in theNotification
trait are made private like all previous types. The companionobjects of
Notification
now have both constructor (apply
) and extractor (unapply
) functions:The nested companion objects of
Notification
now have both constructor (apply
) and extractor (unapply
) functions:To construct a
Notification
, you importrx.lang.scala.Notification._
and useOnNext("hello")
,or
OnError(new Exception("Oops!"))
, orOnCompleted()
.To pattern match on a notification you create a partial function like so:
case Notification.OnNext(v) => { ... v ... }
,or you use the
apply
function to pass in functions for each possibility.There are no breaking changes for notifications.
Java Interop Helpers
Since the Scala traits wrap the underlying Java types, yoo may occasionally will have to wrap an unwrap
between the two representations. The
JavaConversion
object provides helper functions of the formtoJavaXXX
andtoScalaXXX
for this purpose, properly hiding how precisely the wrapped types are stored.Note the (un)wrap conversions are defined as implicits in Scala, but in the unlikely event that you do need them
be kind to the reader of your code and call them explicitly.