I see implementation changes, but I'm not sure what is qualifying as
suggested improvement. I don't think scala-sips is a good place to ask
for review on implementation.
--
On 14 January 2013 09:56, √iktor Ҡlang <viktor...@gmail.com> wrote:
> Feedback?
>
> https://github.com/viktorklang/scala/pull/5/files
>
> --
> Viktor Klang
> Director of Engineering
>
> Typesafe - The software stack for applications that scale
> Twitter: @viktorklang
Daniel C. Sobral
I travel to the future all the time.
I wonder why fallbackTo does not take by-name param, given that it is analogous to getOrElse?
The exception of "this" (as it is now). Will it not be possible if we change the signature like below?def fallbackTo[U >: T](that: => Future[U]): Future[U]
On Sat, Jan 26, 2013 at 4:31 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:
What exception would you expect to be in the resulting Future of "orElse" if both "this" and "that" fails?Cheers,√On Sat, Jan 26, 2013 at 11:55 AM, Mushtaq Ahmed <mush...@gmail.com> wrote:On Sat, Jan 26, 2013 at 4:17 PM, Mushtaq Ahmed <mush...@gmail.com> wrote:I wonder why fallbackTo does not take by-name param, given that it is analogous to getOrElse?I mean orElse.--Viktor Klang
Director of Engineering
Because you lose parallelizability if the rhs is lazy. FallbackTo is extremely useful for farming out work and picking the first success.
Of course you can do that with a lazy rhs but it is more work, i.e. starting computations and the assigning to vals, then passing those in. There's also more overhead (thunk allocations).
(Also, all by-name args in concurrency API introduces a vector of closing over things you didn't intend to.)
That said, I'm not against introducing orElse.
Cheers,
V
Because you lose parallelizability if the rhs is lazy. FallbackTo is extremely useful for farming out work and picking the first success.
--
On Sat, Jan 26, 2013 at 4:22 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:
Because you lose parallelizability if the rhs is lazy. FallbackTo is extremely useful for farming out work and picking the first success.
Ah, okay. I hadn't considered that scenario explicitly. In that case I vote for orElse as well rather than instead of fallbackTo, and for a very clear description in the Scaladocs explaining why and when one would wish to use each (including the first error vs. last error thing).
On Sat, Jan 26, 2013 at 11:26 PM, Rex Kerr <ich...@gmail.com> wrote:
Ah, okay. I hadn't considered that scenario explicitly. In that case I vote for orElse as well rather than instead of fallbackTo, and for a very clear description in the Scaladocs explaining why and when one would wish to use each (including the first error vs. last error thing).
That sounds like a good middle road to me.Anyone else?
--
So the middle ground is:orElse: you get short-circuiting, but the error comes from 'that'fallbackTo: you get parallelism, but the error comes from 'this'This is a bit subtle to remember. If we could fix the error part to be same in both cases, it may be easier.
On Sun, Jan 27, 2013 at 3:58 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:--So: orElse == recoverWith? def orElse[U >: T](that: => Future[U]): Future[U] = recoverWith { case _ => that }or perhaps more efficiently something like:def orElse[U >: T](that: => Future[U]): Future[U] = {val p = Promise[U]()onComplete {case Failure(t) => try p completeWith that catch { case NonFatal(t) => p failure t }case other => p complete other}p.future}On Sun, Jan 27, 2013 at 3:40 AM, Mushtaq Ahmed <mush...@gmail.com> wrote:
On Sun, Jan 27, 2013 at 4:21 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:
On Sat, Jan 26, 2013 at 11:26 PM, Rex Kerr <ich...@gmail.com> wrote:
Ah, okay. I hadn't considered that scenario explicitly. In that case I vote for orElse as well rather than instead of fallbackTo, and for a very clear description in the Scaladocs explaining why and when one would wish to use each (including the first error vs. last error thing).
That sounds like a good middle road to me.Anyone else?Sounds good to me.--Viktor Klang
Director of Engineering
--
The problem though, is that they will just be syntactic sugar for recoverWith, and the question is how the added API adds enough value to warrant the larger surface area.