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.
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.
> 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.
On Monday, November 5, 2012 10:42:21 AM UTC-5, n8han wrote:
> 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.
> > 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.
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?
On Tuesday, November 6, 2012 7:39:40 AM UTC-5, Reuben Doetsch wrote:
> Cleaning everything up and will post later today
> On Monday, November 5, 2012 10:42:21 AM UTC-5, n8han wrote:
>> 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.
>> > 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.
> 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
I will also change in all the documentation, etc...
> Let's call it toEither or futureEither or something along those lines?
> Any preferences?
> Reuben
> On Tuesday, November 6, 2012 7:39:40 AM UTC-5, Reuben Doetsch wrote:
> Cleaning everything up and will post later today
> On Monday, November 5, 2012 10:42:21 AM UTC-5, n8han wrote:
> 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.
> > 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.
On Tuesday, November 6, 2012 2:38:17 PM UTC-5, n8han wrote:
> 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
> I will also change in all the documentation, etc... > > Let's call it toEither or futureEither or something along those lines?
> > Any preferences?
> > Reuben
> > On Tuesday, November 6, 2012 7:39:40 AM UTC-5, Reuben Doetsch wrote:
> > Cleaning everything up and will post later today
> > On Monday, November 5, 2012 10:42:21 AM UTC-5, n8han wrote:
> > 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.
> > > 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.
Reuben Doetsch <hjas...@gmail.com> wrote:
>Just sent an email to the SIPs mailing list and CC'd you.
>On Tuesday, November 6, 2012 2:38:17 PM UTC-5, n8han wrote:
>> 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
>> I will also change in all the documentation, etc... >> > Let's call it toEither or futureEither or something along those
>lines?
>> > Any preferences?
>> > Reuben
>> > On Tuesday, November 6, 2012 7:39:40 AM UTC-5, Reuben Doetsch
>wrote:
>> > Cleaning everything up and will post later today
>> > On Monday, November 5, 2012 10:42:21 AM UTC-5, n8han wrote:
>> > 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.
>> > > 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.
>> Just sent an email to the SIPs mailing list and CC'd you.
>> On Tuesday, November 6, 2012 2:38:17 PM UTC-5, n8han wrote:
>>> 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
>>> I will also change in all the documentation, etc... >>> > Let's call it toEither or futureEither or something along those lines?
>>> > Any preferences?
>>> > Reuben
>>> > On Tuesday, November 6, 2012 7:39:40 AM UTC-5, Reuben Doetsch wrote:
>>> > Cleaning everything up and will post later today
>>> > On Monday, November 5, 2012 10:42:21 AM UTC-5, n8han wrote:
>>> > 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.
>>> > > 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.
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.
>> Just sent an email to the SIPs mailing list and CC'd you.
>> On Tuesday, November 6, 2012 2:38:17 PM UTC-5, n8han wrote:
>>> 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
>>> I will also change in all the documentation, etc... >>> > Let's call it toEither or futureEither or something along those lines?
>>> > Any preferences?
>>> > Reuben
>>> > On Tuesday, November 6, 2012 7:39:40 AM UTC-5, Reuben Doetsch wrote:
>>> > Cleaning everything up and will post later today
>>> > On Monday, November 5, 2012 10:42:21 AM UTC-5, n8han wrote:
>>> > 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.
>>> > > 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.
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.
> 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.
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.
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.
> 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.
> 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 ).
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.
On Friday, November 9, 2012 9:25:32 AM UTC-5, doug wrote:
>> 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 ).
> 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.
On Friday, November 30, 2012 10:33:49 AM UTC-5, n8han wrote: > On 11/30/2012 10:13 AM, Reuben Doetsch wrote:
> > 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.
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.
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?
On Monday, December 3, 2012 2:18:38 AM UTC-5, n8han wrote:
> On Friday, November 30, 2012 10:33:49 AM UTC-5, n8han wrote:
>> On 11/30/2012 10:13 AM, Reuben Doetsch wrote:
>> > 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.
> 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.
On Sun, Dec 9, 2012 at 7:38 PM, n8han <nat...@technically.us> wrote:
> 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?
> On Monday, December 3, 2012 2:18:38 AM UTC-5, n8han wrote:
>> On Friday, November 30, 2012 10:33:49 AM UTC-5, n8han wrote:
>>> On 11/30/2012 10:13 AM, Reuben Doetsch wrote:
>>> > 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.
>> 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.
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.
On Sunday, December 9, 2012 5:38:22 PM UTC-7, n8han wrote:
> 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?
> On Monday, December 3, 2012 2:18:38 AM UTC-5, n8han wrote:
>> On Friday, November 30, 2012 10:33:49 AM UTC-5, n8han wrote:
>>> On 11/30/2012 10:13 AM, Reuben Doetsch wrote:
>>> > 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.
>> 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.
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
El lunes, 5 de noviembre de 2012 13:56:13 UTC, Reuben Doetsch escribió:
> 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.
> 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
> El lunes, 5 de noviembre de 2012 13:56:13 UTC, Reuben Doetsch escribió:
> 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.
> 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
> 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
>> El lunes, 5 de noviembre de 2012 13:56:13 UTC, Reuben Doetsch escribió:
>> 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.
Add me on chat if you want to discuss how to finish up all the interfaces (
hjas...@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.
On Tue, Jan 15, 2013 at 4:08 PM, Luis Ángel Vicente Sánchez <
>> 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
>> 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
>>> El lunes, 5 de noviembre de 2012 13:56:13 UTC, Reuben Doetsch escribió:
>>> 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.
