Naming in Futures - SIP-14, Futures, Try, Either and Option

[Reuben Doetsch]

Hey Everyone,

I am working on a 2.10 integration branch for the new version of async dispatch (Can't get enough of 2.10 -- it's that good)

Dispatch Documentation - http://dispatch.databinder.net/Dispatch.html

Thread Dealing with Update - https://groups.google.com/forum/?fromgroups=#!topic/dispatch-scala/-ZJK7gNG6BQ

Dispatch used it's own Future implementation because it was created before the SIP was live.

I wanted to standardize the implements and use scala.concurrent.Future for 2.10 and a provided implementation for versions lower than 2.10.

So far so good, as I have ported all the code scala.concurrent.Future but there is one breaking change where Nathan or I (creator of Dispatch) does not want to break existing code.  Dispatch contains an "either" method which transforms the Future[A] to a Future[Either[_,A]] which is used heavily in the library. scala.concurrent.Future also contains an either method.

I do not want to break compatibility for a large library and I think that the naming of the either method in Future is strange. The method is not very descriptive and there already exists a Either class in the standard library which now could easily be wrongly associated with having something to do with the either method. I don't care if the method from Future to either exists or not (since I am adding a Future pimp where I can add this), but I do care about the method named either.

Are people very strongly in favor of the name either for the method which choose the first completed future. Wouldn't this more aptly be named, "firstCompleted", "firstComplete", or "getFirstCompleted" or something which describes what it is doing?

Thanks,

Reuben

[Heather Miller]

I think that the reasoning was to differentiate `either` from `firstCompletedOf` (on the Future companion object) which returns the first completed future of a TraversableOnce[Future[T]], i.e. to differentiate between the case of exactly two futures and a collection of an arbitrary number of futures.

While your proposition, i.e. renaming `either` to `firstCompleted` or `firstCompletedOf` or similar is one we'd normally be open to (it's a change I doubt many would have strong feelings against), the trouble is that we've already cut the second RC of 2.10.0, which could very well be 2.10.0-FINAL. I'm afraid it might be too late to rename new methods. Given that, we'd have to go through a deprecation cycle upon the next major release before we could remove it.

Cheers,

Heather

-- 

Heather Miller

Doctoral Assistant

EPFL, IC, LAMP

http://people.epfl.ch/heather.miller

[Heather Miller]

To add a bit of context, I think that the only reason that `either` was ultimately chosen is because it implies that there are only two possibilities-- either A or B. Whereas something else, like firstCompleted intuitively makes no guarantees on the number of futures that we might start with.

Cheers,

Heather

-- 

Heather Miller

Doctoral Assistant

EPFL, IC, LAMP

http://people.epfl.ch/heather.miller

[nicola...@gmail.com]

I think either is a nicer name for choosing either of two futures than to map Right on a future.

--
Sent from an IBM Model M, 15 August 1989.

[√iktor Ҡlang]

This is the sort of discussion that would have been quite much nicer to have 6 months ago.
(and also why it is important to get involved in SIPs if one has a stake in it)

Cheers,

√

On Fri, Nov 9, 2012 at 2:32 AM, Reuben Doetsch <hja...@gmail.com> wrote:

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[martin odersky]

On Fri, Nov 9, 2012 at 11:52 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:

This is the sort of discussion that would have been quite much nicer to have 6 months ago.
(and also why it is important to get involved in SIPs if one has a stake in it)

Yes I agree. In the future, please get involved in SIPs! That's what they are for.

 - Martin

 

--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

[Daniel Sobral]

I'd like to point out that I did raise this issue here in this list, though I never mentioned the method either explicitly (which I now regret).

However, if you followed up on my request for a method that converts a Future[T] into a Future[Either[Exception, T]], I'm pretty sure either's name would have come up.

--
Daniel C. Sobral

I travel to the future all the time.

[√iktor Ҡlang]

What happens if the Future[Either[Exception, T]] is failed?

[Chris Marshall]

I think it is fair to say that general experience is that people only actually get involved after the API is roughly worked out and it doesn't quite look like they expected. It might be a better idea to work this observation into the SIP workflow - I know it must be extremely frustrating for the people behind the SIP.

How would it be worked into the SIP workflow? By having less up-front discussion and rushing headlong into an (intentionally poor) implementation which is presented as a fait accompli to the community at large, who then go ballistic and offer vocal feedback. I understand this approach is being trialed by the JDK8 lambda guys.

Chris

[√iktor Ҡlang]

There's no solution to this problem, there will always be people who migrate years after something is released and start commenting about perceived deficiencies.

(I for one wouldn't want to be on Lambda – 90% of the feedback is just not constructive.)

However, I think people generally need to engage more in the things which they have a stake in, or just delegate to others and forfeit their right to whine – which is why I spent a lot of my spare time (which there is very little of) to be involved in SIP-14 – to be a part of the solution and not the problem.

Cheers,

√

[Daniel Sobral]

On Fri, Nov 9, 2012 at 10:41 AM, Chris Marshall <oxbow...@gmail.com> wrote:

I think it is fair to say that general experience is that people only actually get involved after the API is roughly worked out and it doesn't quite look like they expected. It might be a better idea to work this observation into the SIP workflow - I know it must be extremely frustrating for the people behind the SIP.

How would it be worked into the SIP workflow? By having less up-front discussion and rushing headlong into an (intentionally poor) implementation which is presented as a fait accompli to the community at large, who then go ballistic and offer vocal feedback. I understand this approach is being trialed by the JDK8 lambda guys.

I'm not sure if that's humor or not, nor do I deny the essential truth of it, but lol!

 

Chris

On Fri, Nov 9, 2012 at 10:52 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:

This is the sort of discussion that would have been quite much nicer to have 6 months ago.
(and also why it is important to get involved in SIPs if one has a stake in it)

Cheers,

√

[Daniel Sobral]

On Fri, Nov 9, 2012 at 10:41 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:

What happens if the Future[Either[Exception, T]] is failed?

What do you mean by "is failed"?

[√iktor Ҡlang]

contains a Failure instead of a Success

[Ismael Juma]

On Fri, Nov 9, 2012 at 12:51 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

However, I think people generally need to engage more in the things which they have a stake in, or just delegate to others and forfeit their right to whine – which is why I spent a lot of my spare time (which there is very little of) to be involved in SIP-14 – to be a part of the solution and not the problem.

I agree that people should get involved as early as they can. They should not forfeit the right to provide feedback late in the process though. As long as they understand that it may be harder and take more time for actions to be taken based on the feedback. After all, software is constantly improving and part of the reason is that feedback happens continuously.

Best,

Ismael

[Daniel Sobral]

On Fri, Nov 9, 2012 at 11:04 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:

contains a Failure instead of a Success

It becomes a Success(Left(ex)). The point of toEither (Dispatch's Promise.either) is pretty much making sure methods called on it will work as if it was a success. For example, map and flatMap should receive and act on the Either, be it a Left or a Right.

[Reuben Doetsch]

Thanks everyone for the reply,

@Heather - I understand why the general idea behind why it was named, but just had an issue with the name "either" (for the reasons listed). Obviously many of them are selfish in that I want to be able to migrate and create a easy migration from dispatch_2.9.2 to dispatch_2.10.0. Even without my selfish interest, either seems like a strange name ( https://twitter.com/n8han/status/265902526036066305 -- please don't crucify for me using Twitter for proof of anything).

@oxbows - I don't think anything can be done to the SIP workflow other than what Viktor said, which is to be more involved. 

@martin, @viktor - I wish I had been more involved in the process ( I am relatively new to Scala ), but I think Nathan was involved early on and added SIP methods to the Future, but either was added after this effort had been done. The SIP changed a lot and I think Nathan only looked at it at a few snapshots in time. I wanted to bring this up before 2.10.0-FINAL came out, but didn't realize that everyone is thinking only two RC's. 

I am assuming by all the messages that there is no way to start a conversation about changing the name right now and for dispatch I should start migrating code to use a new name. If it helps, I will volunteer my time to change documentation, code, or whatever related to the name.

Thanks again,

Reuben

[Aleksandar Prokopec]

On 11/9/12 2:01 PM, Daniel Sobral wrote:

On Fri, Nov 9, 2012 at 10:41 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:

What happens if the Future[Either[Exception, T]] is failed?

What do you mean by "is failed"?

 

I think he means that you do:

f.either.map(x => (throw Exception): Either[Exception, T])

which would give you back a Future[Either[Exception, T]], but the future itself would be failed, whereas a user might expect the future to contain a Left(Exception) instead.

Cheers,
Alex

[√iktor Ҡlang]

But that is my point, there is no way to enforce that at a type level.

def bippy(f: Future[Either[Exception, T]]) = …

bippy(Future.failed(new OhnoesException))

[√iktor Ҡlang]

On Fri, Nov 9, 2012 at 2:10 PM, Reuben Doetsch <hja...@gmail.com> wrote:

Thanks everyone for the reply,

@Heather - I understand why the general idea behind why it was named, but just had an issue with the name "either" (for the reasons listed). Obviously many of them are selfish in that I want to be able to migrate and create a easy migration from dispatch_2.9.2 to dispatch_2.10.0. Even without my selfish interest, either seems like a strange name ( https://twitter.com/n8han/status/265902526036066305 -- please don't crucify for me using Twitter for proof of anything).

We were discussing quite a few names: "or", "race" ("or" was problematic because people assumed it to take the first successful value) ("race" is a problematic name)

 

@oxbows - I don't think anything can be done to the SIP workflow other than what Viktor said, which is to be more involved. 

@martin, @viktor - I wish I had been more involved in the process ( I am relatively new to Scala ), but I think Nathan was involved early on and added SIP methods to the Future, but either was added after this effort had been done. The SIP changed a lot and I think Nathan only looked at it at a few snapshots in time. I wanted to bring this up before 2.10.0-FINAL came out, but didn't realize that everyone is thinking only two RC's. 

Things like these need to be raised pre-RC (there might only be one) – but I definitely want them to be raised, so please get involved sooner :-)

 

I am assuming by all the messages that there is no way to start a conversation about changing the name right now and for dispatch I should start migrating code to use a new name. If it helps, I will volunteer my time to change documentation, code, or whatever related to the name.

val firstOf = future2 <insert suggested name here> future2

val firstOf = future firstCompletedOf future2 //Clashes with Future.firstCompletedOf and is also quite unpleasant visually

val firstOf = future race future2

val firstOf = future || future2 // doesn't have the right semantics, people expect short-circuit

Perhaps the right solution is to remove the method?

Cheers,

√

[Daniel Sobral]

On Fri, Nov 9, 2012 at 11:12 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:

But that is my point, there is no way to enforce that at a type level.

def bippy(f: Future[Either[Exception, T]]) = …

bippy(Future.failed(new OhnoesException))

I'm sorry but that's completely outside scope.

See, it is my intention as *the caller* to ensure that the *receiver* will get a future where any present failure becomes a success of a left.

It's not about what I'm receiving, but about what I'm sending.

[reuben doetsch]

Thanks Viktor,

How about

val firstOf = future firstCompleted future2

since adding the "firstCompletedOf" implies there are multiple objects on the right side (by using the word of)

or 

val firstOf = future getOrFirst future2

Reuben 

--
Thanks,

Reuben Doetsch
CTO & CoFounder Sportaneous.com

[Daniel Sobral]

On Fri, Nov 9, 2012 at 11:29 AM, Daniel Sobral <dcso...@gmail.com> wrote:

On Fri, Nov 9, 2012 at 11:12 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:

But that is my point, there is no way to enforce that at a type level.

def bippy(f: Future[Either[Exception, T]]) = …

bippy(Future.failed(new OhnoesException))

I'm sorry but that's completely outside scope.

See, it is my intention as *the caller* to ensure that the *receiver* will get a future where any present failure becomes a success of a left.

It's not about what I'm receiving, but about what I'm sending.

I thought of another point here. If I were "bippy" and wanted to ensure I would not get a failure, I'd get a normal feature, and then, myself, call either-or-whatever on it.

[Chris Marshall]

I am always about the lols

[√iktor Ҡlang]

I'd suggest using the "transform" method instead of involving Either.

[√iktor Ҡlang]

Exactly, so there is not much need for the Either-thingy. Also, "transform" is a very nice method.

[Philipp Haller]

On Nov 9, 2012, at 2:19 PM, √iktor Ҡlang wrote:

I am assuming by all the messages that there is no way to start a conversation about changing the name right now and for dispatch I should start migrating code to use a new name. If it helps, I will volunteer my time to change documentation, code, or whatever related to the name.

val firstOf = future2 <insert suggested name here> future2

val firstOf = future firstCompletedOf future2 //Clashes with Future.firstCompletedOf and is also quite unpleasant visually

val firstOf = future race future2

val firstOf = future || future2 // doesn't have the right semantics, people expect short-circuit

Perhaps the right solution is to remove the method?

I think that removing the method could be a workable solution. After all, it's got a very simple implementation in terms of Promise and tryComplete.

Cheers,

Philipp

[Philipp Haller]

On Nov 9, 2012, at 2:42 PM, Philipp Haller wrote:

On Nov 9, 2012, at 2:19 PM, √iktor Ҡlang wrote:

I am assuming by all the messages that there is no way to start a conversation about changing the name right now and for dispatch I should start migrating code to use a new name. If it helps, I will volunteer my time to change documentation, code, or whatever related to the name.

val firstOf = future2 <insert suggested name here> future2

val firstOf = future firstCompletedOf future2 //Clashes with Future.firstCompletedOf and is also quite unpleasant visually

val firstOf = future race future2

val firstOf = future || future2 // doesn't have the right semantics, people expect short-circuit

Perhaps the right solution is to remove the method?

I think that removing the method could be a workable solution. After all, it's got a very simple implementation in terms of Promise and tryComplete.

As an end result I mean.

How to go about deprecation etc. is a separate issue.

[Aleksandar Prokopec]

On 11/9/12 2:42 PM, Philipp Haller wrote:

On Nov 9, 2012, at 2:19 PM, √iktor Ҡlang wrote:

I am assuming by all the messages that there is no way to start a conversation about changing the name right now and for dispatch I should start migrating code to use a new name. If it helps, I will volunteer my time to change documentation, code, or whatever related to the name.

val firstOf = future2 <insert suggested name here> future2

val firstOf = future firstCompletedOf future2 //Clashes with Future.firstCompletedOf and is also quite unpleasant visually

val firstOf = future race future2

val firstOf = future || future2 // doesn't have the right semantics, people expect short-circuit

Perhaps the right solution is to remove the method?

I think that removing the method could be a workable solution. After all, it's got a very simple implementation in terms of Promise and tryComplete.

Cheers,

Philipp

I agree with this - seems like the safest course of action. It can always be added back with a different name in a later release if necessary.

Cheers,
Alex

[√iktor Ҡlang]

I also agree with this.

But that means we need to cut an RC3.

[Philipp Haller]

And that addition could come in a follow-up SIP, such as SIP-14b. People would then hopefully get involved earlier with SIP-14b.

Philipp

[Daniel Sobral]

Transform can't be used to feed a pattern match, and it's excessively verbose when I just want an Either. Hey, Either has precedence: it was here first. Be nice to it.

[Rex Kerr]

On Fri, Nov 9, 2012 at 8:19 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:

val firstOf = future || future2 // doesn't have the right semantics, people expect short-circuit

val firstOf = future | future2  // People don't expect short-circuit!

  --Rex

P.S. I prefer not using "either" to mean "or".  For example: we could rename this method either remove it entirely.  Huh?!

[Reuben Doetsch]

@Viktor + @Martin - What is the best course of action?

[√iktor Ҡlang]

Reuben: To achieve what end?

[reuben doetsch]

Based on this thread it seems like many people are in favor of either (pun not intended) a change of name or a deprecation. I know personally I am and it would be great for backwards compatibility with dispatch.

I would love to see if it possible to either get a SIP-14B rolling, or change the name or deprecate?

I know it might be too late for 2.10, but if something could happen before 2.10.0-FINAL it would be great. Again I free all day and tomorrow to do any necessary work if people agree on it.

If we the change won't happen, I also would love to know so I can figure out a backwards solution to write and release dispatch for 2.10.

Thanks for taking my concern,

Reuben

[Daniel Sobral]

Personally, I think the best course of action at this point is to keep the name "either", unless many more people complain about it once 2.10.0 is out.

[√iktor Ҡlang]

The only option I see is to remove it completely in the next Scala 2.10 RC (if there is another one).

As for having a method that lifts a Future[T] to Future[Either[Throwable, T]] I think I've already been clear on the fallacy of such a method.

Cheers,

√