Scala 2.10 and possible scala.concurrent.Future interlop

[Reuben Doetsch]

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

[Nathan Hamblen]

Hi Reuben, could you link to your fork with the changes?

As far as the naming goes, I don't feel very strongly about it. The use
of "promise" in Dispatch predates sip-14; the popular consensus, as I
observed it, was that a promise is a future that composes without
blocking. I was pretty surprised when the sip was published and it
followed a different convention. 9 months later, here we are still.

Since the term is used throughout the Dispatch code and documentation I
wasn't going to change it but, if you're volunteering to do that in a
backwards compatible way, that's great. (Please replace all "promise"
puns in the docs with "future" puns. Just kidding. Sort of.) We'll merge
and release with it as soon as 2.10 final is released.

Nathan

[Reuben Doetsch]

Cleaning everything up and will post later today

[Reuben Doetsch]

So I am almost finished coding the solution but we have another naming issue. 

The issue is that there already exists an either method in scala.concurrent.Future so I think we should rename Future[T].either to something else now. I will also change in all the documentation, etc... Let's call it toEither or futureEither or something along those lines?

Any preferences?

Reuben

[Nathan Hamblen]

On 11/06/2012 12:20 PM, Reuben Doetsch wrote:
> So I am almost finished coding the solution but we have another naming
> issue.
>
> The issue is that there already exists an either method in
> scala.concurrent.Future so I think we should rename Future[T].either to
> something else now.

For some values of "already". :) scala.concurrent.Future.either was not
even in the last SIP-14 draft that I read. But, great, there it is:

> The either combinator creates a new future which either holds the
result of this future or the argument future, whichever completes first,
irregardless of success or failure.

This is some strangely bad naming considering there is a type called
scala.Either. I'm going to have to think about what to do. I'm not ready
to commit to a breaking change that is also a step back in readability.
I don't suppose there is any chance of talking sense to the SIP creators?

Nathan

[Reuben Doetsch]

Just sent an email to the SIPs mailing list and CC'd you.

[Nathan Hamblen]

Thanks, we'll see what happens!

[Reuben Doetsch]

Check out the sip thread https://groups.google.com/forum/?fromgroups=#!topic/scala-sips/VRlDgX4yFKE and since you have more klout with the scala community than me would love your input into the discussion.

Reuben

[Daniel Sobral]

I think it's unlikely anything will change there. I raised the issue before, though I did not go after that method's name, since I did not think of anything better, and did not feel strongly against it.

Now, I'm pretty much a newbie user of Dispatch, but I'll put in my two cents. I personally prefer the name Future over the name Promise, but I think adhering to the convention set forth by Scala 2.10 is even more important.

As for the class/implicit stuff, I prefer that 2.10's Future be used, with missing methods added through a pimp. That will make it possible to combine Dispatch futures with futures returned by other libraries. I have a use case with Scala I/O right now, for instance.

As for a new name for either, I think toEither would be best, as it follows 2.10's Try "toOption" naming convention.

[Reuben Doetsch]

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

[Reuben Doetsch]

convince*

[Nathan Hamblen]

If I enter that thread it will turn into an argument over their evident disregard for the libraries that they expect to implement their common interface, not having surveyed these libraries in the many months their SIP has been in formative stages. And that won't go anywhere.

I'll email one of the friendlier people at typesafe and see how that goes. Thanks again Reuben for discovering the problem.

Nathan

[Doug Tangren]

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 ).

For some reason I thought Exception.Catch defined an `eth` which I was going to suggest, but I think I was thinking instead of `opt`. Funny enough, Exception.Catch defines both an either and toEither - http://www.scala-lang.org/api/current/scala/util/control/Exception$$Catch.html 

[Reuben Doetsch]

Status Update on Future rename:

Okay so after I pushed back on the Future team, the either method was removed in RC3 and so I got everything working and compiling. The only issue is that the test code coverage requires netty-unfiliterd 2.10 which in turn requires specs2 2.10 (unfiltered uses specs 1). Do you have plans to publish a 2.10 unfiltered version or should I rewrite some test suites.

Reuben

[Nathan Hamblen]

On 11/30/2012 10:13 AM, Reuben Doetsch wrote:
> Status Update on Future rename:
>
> Okay so after I pushed back on the Future team, the either method was
> removed in RC3 and so I got everything working and compiling.

Nice work!

> The only
> issue is that the test code coverage requires netty-unfiliterd 2.10
> which in turn requires specs2 2.10 (unfiltered uses specs 1).

Yeah, I've been commenting out a few things to make the Dispatch builds
for 2.10 work.

> Do you
> have plans to publish a 2.10 unfiltered version or should I rewrite some
> test suites.

Certainly... after the release of 2.10. But I'm persuaded that it's
worth making this switch in Dispatch prior to 2.10's release, so I'll
come up with something this weekend to make the build work properly.

Nathan

[n8han]

I changed my mind and published a "2.10" artifact for some modules of unfiltered 0.6.4, built with RC3. I also pushed some changes to master and am now able to run the tests against core using 2.10.

The tests hang before all suites are run but that's unrelated, happens on 2.9 as well.

Nathan

[n8han]

Hi Reuben, I'd like to release something prior to Scala 2.10's release if possible, so people can get used to the new naming. Is your fork ready to pull?

[reuben doetsch]

Sorry got sidetracked and releasing a new version of app tomorrow. Will make sure to make this a priority by early this week ( Monday- Tuesday)

--
Thanks,

Reuben Doetsch
CTO & CoFounder Sportaneous.com

[Lanny Ripple]

I'd like to pitch that artifacts be published that track the Scala 2.10 Release Candidates when all this comes together.  We've got a large system that makes heavy use of Dispatch and I'd like to get ahead of 2.10 testing.

  -ljr

[langel...@gmail.com]

Hi!

I have been using dispatch for a while and is a great library! I am really interested on the state of this change as I'm using Play2.1 as my development framework and the possibility that dispatch returns scala.concurrent.Future would make it a great addition to my stack.

Kind regards,

Luis

[Nathan Hamblen]

On 01/15/2013 02:37 PM, langel...@gmail.com wrote:
> Hi!
>
> I have been using dispatch for a while and is a great library! I am
> really interested on the state of this change

Hi Luis, this is it:
https://github.com/dispatch/reboot/tree/scala210

There are few files totally commented out because their functionality
has not been ported to the new interface, but it's reasonably close.

A few more pull requests would speed this to completion -- planning
nescala is taking up almost almost all my time lately.

Nathan

[Luis Ángel Vicente Sánchez]

Thank you! I will take a look.

[reuben doetsch]

Add me on chat if you want to discuss how to finish up all the interfaces (hja...@gmail.com). Real life has got in the way of this in the last few weeks, but hopefully I can also add support after a big deadline.