I made this public because as currently designed anyone implementing a Scheduler will almost certainly want to use this.

Copy/pasting from https://github.com/Netflix/RxJava/pull/229#issuecomment-16487214:

----

The .Net implementation is able to use extension methods to make the design much more elegant where only the main 3 methods are part of the Scheduler interface and the rest come along for the ride.

It means we end up with a Scheduler/AbstractScheduler Interface/Abstract pairing to make this work.

Should we just make Scheduler an Abstract? I'm very tempted to do so because of the following problems:

- adding methods to Scheduler will be breaking changes requiring major version increments
- people implementing Schedulers will basically always have to also extend AbstractScheduler or copy/paste all of those method overloads

Or should be remove all but the main 3 methods from Scheduler and put all the overloads as utility functions on the Schedulers class instead?

The precedent for using abstract (or concrete) classes instead of interfaces (which .Net then augments with extension methods) is already done - Observable is a concrete class instead of interface for this very reason.

All plugins are done as abstracts instead of interfaces for this reason as well.

Thoughts?