> 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 ).
> 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.
> 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.
> - For scala 2.9 and down keep all the same code but rename
> Promise to Future
> - For 2.10 create a conditionally compiled execution.scala
> which returns scala.concurrent.Future instead of a
> - 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
> - 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.