-
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
A few basic Swing observables #262
Conversation
probably be lots more methods in the long run.
I haven't played with Swing in a very long time but this looks great! |
* See the License for the specific language governing permissions and | ||
* limitations under the License. | ||
*/ | ||
package rx; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm considering the placement in the rx.
package.
Does it make more sense in rx.observables
or rx.swing
?
Thus far we've kept rx
to be only the most foundational classes so this seems out of place in that package (and I realize it's coming from a contrib module which is what makes me further wonder if it should be completely namespaced into rx.swing
).
RxJava-pull-requests #133 SUCCESS |
I don't know. I intuitively placed it directly under I would also be okay with putting everything under |
This would mean moving the SwingScheduler, too, though, to something like |
A namespaced package makes sense for things that don't fit in the other packages (as you've done), but I agree with your assessment of Perhaps |
Placing it inside |
Okay ... sorry about being pedantic on this but whatever we do here sets precedent for all modules we add in the future. Even this decision leaves open the possibility of naming collisions between modules but I'm fine with dealing with that as this approach leaves the usage more natural. The only other thing I've considered is whether it should be |
No problem. I agree that these decisions are quite important. I don't mind at all changing this around in order to make the API better. Concerning I'm okay with naming it |
Interesting consideration, Subscriptions and Schedulers don't do that great a job in this regard. I like the 'observe' verb prefix though it implies it immediately subscribes which it does not, it returns a lazy Observable you then observe by subscribing to it. I think 'from', 'toObservable', 'create' are the right type of prefixes. Still thinking ... |
Another consideration, nothing prevents extending from Observable in the future to add custom operators specific to Swing. Keep it as SwingObservable with 'from' factory methods I think. |
Alright, good. |
A few basic Swing observables
A few basic Swing observables
This adds a few observables for observing common button click, keyboard and mouse events.