Talk:Futures and promises

From Wikipedia, the free encyclopedia

Contents

[edit] Requested move

The following discussion is an archived discussion of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.


Future (programming) → Futures and promises (programming) — The scope of the article has been changed to reflect the fact that there is a technical distinction between "futures" and "promises" in several programming languages (although they are very similar and should still be covered by the same article). DavidHopwood 01:23, 22 March 2007 (UTC)

[edit] Survey

Add  # '''Support'''  or  # '''Oppose'''  on a new line in the appropriate section followed by a brief explanation, then sign your opinion using ~~~~. Please remember that this survey is not a vote, and please provide an explanation for your recommendation.

[edit] Survey - in support of the move

[edit] Survey - in opposition to the move

I added some material to clarify the definition of futures. After doing so, it seems to me that a similar definition of promisises is badly needed since the promise concept seems highly ambiguous.--2ndMouse 14:03, 24 March 2007 (UTC)

[edit] Discussion

Add any additional comments:

Is the "(programming)" disambiguation really needed? Futures and promises is also a redlink, and I suspect that somebody would just move the article there later, because we're not distinguishing futures and promises in programming from some other "futures and promises". -GTBacchus(talk) 02:48, 28 March 2007 (UTC)

The above discussion is preserved as an archive of the proposal. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.
Even with the additions that 2ndMouse suggests, the article would still cover both futures and promises, and as GTBacchus points out, there is no need for the disambiguating term. Future (programming) has been moved to futures and promises as the result of a move request. Stemonitis 08:06, 28 March 2007 (UTC)

[edit] "Promise" term

I really don't believe that the use of the definition of "Promise" is the correct term to be used in this article, but rather "expectations". Humans expect things that are better than was previously presented before, and this is the future of anything. Everything that has been invented and engineered was due to to the fact that people were confronted with a limited problem that involved the expectations of something better. To promise something would imply that a time machine would have already been invented, for example. It is more accurate to say that the belief in the invention of a time machine by now was a possibility, or even an expection, in that era. To promise this would guarantee that it was definitely a reality now. That is if a promise is like anything my loving girlfriend pulls off time and time again. I've had a few drinks in the past few hours, so I hope I make some sense. E-mail me if you have any questions, I'm sure I'd find it entertaining arguing with you. Bring it on nerds. cerulean_flame@yahoo.com

Well, since Wikipedia documents, not invents, the issue is a bit moot. They're called "futures" and "promises" in the field, so calling them anything else on Wikipedia will just confuse matters. (Oh, and where i come from, you can only make promises about the future, and promises can be broken. :) --Piet Delport 12:47, 10 January 2006 (UTC)

[edit] Java 1.5 Futures

Is there any relation to Future interface in the Java API?

Not really. You can think of Java's Future as a one-element, one-shot, thread-safe result queue. It's useful for thread synchronization, but doesn't implement any of the techniques described in this article. --Piet Delport 10:46, 3 February 2006 (UTC)
Yes there is; FutureTask implements an "explicit future". The article now describes the difference between this and the implicit futures/promises implemented by most of the other languages mentioned. --DavidHopwood 02:20, 21 March 2007 (UTC)
Addendum: As the article mentions, there is a dialect of Java, called Flow Java, which does implement single-assignment and future variables. The website has a nice paper and presentation about how they are used, and what kind of problems they can solve. --Piet Delport 09:52, 5 April 2006 (UTC)

[edit] Twisted's Deferred

Is this the same as Twisted's deferred object? If not, how does it differ?

Not meaningfully. Deferreds are similar to Java 1.5's Future, discussed above; the main difference is that they're usually used without threads, and have their results processed by a dual callback/errback chain instead of a polling/blocking caller. --Piet Delport 23:55, 19 September 2006 (UTC)
That's correct, although this feature of Twisted was inspired by promises in E. The differences are mainly due to the fact that Twisted is strictly a library/framework; it doesn't change the Python language. --DavidHopwood 02:24, 21 March 2007 (UTC)