>       /convince*/

> On Friday, November 9, 2012 7:53:11 AM UTC-5, Reuben Doetsch wrote:

>     If Nathan can't conceive them to do anything (which I assume we
>     won't ), I am +1 for toEither (still annoying since used so
>     heavily throughout the example, and probably existing code ).

>     Reuben

>     On Monday, November 5, 2012 8:56:13 AM UTC-5, Reuben Doetsch wrote:

>         Hey Dispatchers,

>         I have been using a lot of reboot and also a lot of scala 2.10
>         ( macro love ). I would love to use both together and have
>         some questions / areas for thought about scala 2.10 support
>         and possible changes to reboot.

>         Areas to Consider

>         A few areas to consider when building / starting to use reboot
>         in 2.10;

>         a.) The reboot implementation of Promise is really nice but I
>         am concerned that when you what to use scala 2.10 using the
>         name Promise will be confusing since Scala 2.10 has a version
>         of Promise (which is more the write-only side), which is not
>         consistent with Dispatch Promise (which mirrors more the
>         concept of Future in Scala). Obviously this is semantics, but
>         could make a difference in both maintaining compatiblity and
>         making it easier to migrate late.
>         b.) Use scala implementation of future while at the same time
>         maintaining the same interlope for pre-2.10 people.

>         Proposal

>         What I propose ( and I have coded, but open to coding anything
>         which everyone agrees on since I want this to be part of main
>         reboot since I think dispatch is the defacto solution for HTTP
>         requests in scala):

>         -Rename Promise[T] to Future[T]. I think that conceptually the
>         2.10 futures are very similar to dispatch promises and I think
>         using the scala standard naming is easiest. This also makes it
>         easier to conditionally compile code for both 2.10 and 2.9,
>         2.8, since only code in one or two files has to change.

>         2.9
>         - For scala 2.9 and down keep all the same code but rename
>         Promise to Future

>         2.10.0

>         - For 2.10 create a conditionally compiled execution.scala
>         which returns scala.concurrent.Future instead of a
>         dispatch.Future
>         - Create an scala.concurrent.Future pimp which adds the
>         methods missing in scala.concurrent.Future
>            - left
>            - right
>            - flatten
>            - overrided toString

>         The rest of the code should not have to change. The only
>         possible issues are that a few of the method signiatures are
>         slightly different in scalas Future.

>         I think this solution does the following:
>          - Creates a rather easy migration path from pre-2.10 to 2.10
>         (by keeping the same name and adding pimps for methods used)
>          - Only have to maintain 1-2 files for pre-2.10 and 2.10
>         (promise.scala and execution.scala right now)

>         I will anemable to do all necessary changes (both to the
>         library and to the documentation) if people would be up for this.

>         Other Options

>         - Make dispatch.Future extend Future and then nothing needs to
>         change from one version to the other
>             - This slightly complicates the solution and makes it more
>         annoying as the scala future library changes
>         - Have an explicit from dispatch.Promise to
>         scala.concurrent.Future
>            - Performance wise this is not great

>         I also implemented both of the above, but the naming confusion
>         and inconsistency proved too much of a problem ( it kept auto
>         importing scala.concurrent.Promise ) and I didn't want to add
>         a layer of indirection unnecessarily if all standard libraries
>         implement scala.concurrent ( a la akka ).

>         Any feedback would be greatly appreciated and would love to
>         discuss the possibilities surrounding this further.

>         Thanks,

>         Reuben