On Feb 18, 2014, at 11:38 PM, C. Scott Ananian wrote:
[resending to list, original was sent from wrong address and got bounced]
On Tue, Feb 18, 2014 at 11:12 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Feb 18, 2014, at 12:44 PM, C. Scott Ananian wrote:
```js
var SubPromise =
On Sat, Feb 15, 2014 at 5:17 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Feb 14, 2014 at 10:50 PM, C. Scott Ananian
ecmascr...@cscott.net wrote:
Since both Chrome and FIrefox have plans to support Promises, feel
free to suggest any changes to `es6-shim` which would improve
On 18 February 2014 10:43, Yehuda Katz wyc...@gmail.com wrote:
On Sat, Feb 15, 2014 at 5:17 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Feb 14, 2014 at 10:50 PM, C. Scott Ananian
ecmascr...@cscott.net wrote:
Since both Chrome and FIrefox have plans to support Promises, feel
free
On Tue, Feb 18, 2014 at 10:29 AM, C. Scott Ananian csc...@cscott.netwrote:
Yes, and I'm pointing out that you can subclass built-ins in a compatible
manner even without the @@create hook,
How?
and hoping that we might see support for that (for Promises at least;
maybe Map/Set as well).
You can do so in the manner you were always able to in ES5, and you were able
to do in ES6 before the introduction of @@create. However, what this means is
that you now allow parastic inheritance again, which @@create was created to
disallow.
That is, you could have a MapPromiseWeakMap just by
On Feb 18, 2014, at 10:39 AM, Domenic Denicola wrote:
You can do so in the manner you were always able to in ES5, and you were able
to do in ES6 before the introduction of @@create. However, what this means is
that you now allow parastic inheritance again, which @@create was created to
Yes. For these same reasons, Date.call(obj) already doesn't work in ES5.
On Tue, Feb 18, 2014 at 10:54 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Feb 18, 2014, at 10:39 AM, Domenic Denicola wrote:
You can do so in the manner you were always able to in ES5, and you were
able to
From: Allen Wirfs-Brock al...@wirfs-brock.com
No, even if you removed the checks in Map and Promise and WeakMap that
prevent them from trying to initialize an object that lacks the appropriate
internal slots it still wouldn't work because obj does not have the internal
slots necessary to
Domenic Denicola wrote:
Well, but you could just move the internal slot initialization into the
constructor itself (as Scott has done in his es6-shim promises). Unlike e.g.
`Array`, the objects returned by `Promise[@@create]` are not exotic objects;
they are simply normal objects with some
The same rationale would apply to Date, but making this change for Date
would be a breaking change. For consistency, let's not pick and choose
among builtins this way. We'll have @@create soon enough.
On Tue, Feb 18, 2014 at 11:09 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From:
is what they want to do in the meantime.
From: Mark S. Miller erig...@google.com
Sent: Tuesday, February 18, 2014 14:16
To: Domenic Denicola
Cc: Allen Wirfs-Brock; C. Scott Ananian; Brendan Eich; Yutaka Hirano;
es-discuss@mozilla.org list
Subject: Re: Promise.cast
On Feb 18, 2014, at 11:09 AM, Domenic Denicola wrote:
From: Allen Wirfs-Brock al...@wirfs-brock.com
No, even if you removed the checks in Map and Promise and WeakMap that
prevent them from trying to initialize an object that lacks the appropriate
internal slots it still wouldn't work
On Tue, Feb 18, 2014 at 11:23 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Feb 18, 2014, at 11:09 AM, Domenic Denicola wrote:
From: Allen Wirfs-Brock al...@wirfs-brock.com
No, even if you removed the checks in Map and Promise and WeakMap that
prevent them from trying to
On Feb 18, 2014, at 12:44 PM, C. Scott Ananian wrote:
ps. I'm talking about this pattern in particular:
```js
var SubPromise = function(exec) { Promise.call(this, exec); ... };
Object.setPrototypeOf(SubPromise, Promise);
SubPromise.prototype = Object.create(Promise.prototype);
On 2/18/14 2:51 PM, Allen Wirfs-Brock wrote:
I'm also a bit concerned, that there may be a meme starting that it will
be a looong time (years, if ever) before @@create is actually
implemented so JS developers really shouldn't count on being able to use
it if the foreseeable future. Such a
On Feb 18, 2014, at 1:12 PM, Boris Zbarsky wrote:
On 2/18/14 2:51 PM, Allen Wirfs-Brock wrote:
I'm also a bit concerned, that there may be a meme starting that it will
be a looong time (years, if ever) before @@create is actually
implemented so JS developers really shouldn't count on
On 2/18/14 4:34 PM, Allen Wirfs-Brock wrote:
In that case, i don't see why the DOM is a barrier to adding @@create to JS.
It's not, and I'm not quite sure where you thought I said it was
I was talking about actual uses of subclassing for DOM objects.
Maybe we should make DOM
On Feb 18, 2014, at 1:49 PM, Boris Zbarsky wrote:
On 2/18/14 4:34 PM, Allen Wirfs-Brock wrote:
You don't necessary need a new slot to to use as an initialized flag. I most
cases you can probably get away with using a not yet initialized token in
some existing slot.
While true, doing
On Tue, Feb 18, 2014 at 3:34 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Of course adding an extra internal slot to all DOM objects is not
necessarily all that great either... Though maybe we have to do that no
matter what to prevent double-initialization.
You don't necessary need a
On Feb 18, 2014, at 4:59 PM, Jason Orendorff wrote:
On Tue, Feb 18, 2014 at 3:34 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Of course adding an extra internal slot to all DOM objects is not
necessarily all that great either... Though maybe we have to do that no
matter what to
On 2/18/14 4:57 PM, Allen Wirfs-Brock wrote:
I think that could be handled generically in the WebIDL spec. You can specify
it as if there was a per object initialized flag. But how that state is
actually represented can be left to actual implementations to deal with.
Yeah, agreed. I came
[resending to list, original was sent from wrong address and got bounced]
On Tue, Feb 18, 2014 at 11:12 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Feb 18, 2014, at 12:44 PM, C. Scott Ananian wrote:
```js
var SubPromise = function(exec) { Promise.call(this, exec); ... };
On Sat, Feb 15, 2014 at 3:17 AM, Anne van Kesteren ann...@annevk.nl wrote:
It will take a long time before browsers support subclassing in
general as far as I can tell.
I'm not talking about the class system in general. I'm talking about
the ES5+ code:
```js
Promise.prototype.bind =
On Fri, Feb 14, 2014 at 10:50 PM, C. Scott Ananian
ecmascr...@cscott.net wrote:
Since both Chrome and FIrefox have plans to support Promises, feel
free to suggest any changes to `es6-shim` which would improve
compatibility. It looks like that at the moment the `es6-shim`
implementation is
On Fri, Feb 7, 2014 at 11:50 AM, Anne van Kesteren ann...@annevk.nl wrote:
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=966348 on Gecko
when the news broke. Mozilla can probably still make things in order
before promises hit stable.
To be clear, we fixed this. And we will be going
On Fri, Feb 14, 2014 at 6:21 AM, Anne van Kesteren ann...@annevk.nl wrote:
To be clear, we fixed this. And we will be going ahead and shipping
promises in Firefox 29. Too many dependencies at this point to hold of
longer.
Since both Chrome and FIrefox have plans to support Promises, feel
free
On Sun Feb 9 07:30 PM, Brendan Eich wrote:
Jonathan Bond-Caron wrote:
Thoughts on adding options/flags
Just say no.
http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html
This is a symptom. We are resisting the larger issue of do both or
design-by-
committee unioning
On Fri Feb 7 12:14 PM, Tab Atkins Jr. wrote:
From a user perspective, can someone explain what chain() does?
.chain returns what is directly inside the promise, without doing any
additional
magic. This is different from .then, which flattens
promises.
For a more concrete example,
16:05:20 -0500
Subject: Re: Promise.cast and Promise.resolve
A *working* implementation should be created and solutions to
real-world use cases should be programmed using the design before any spec
language is authored. Spec-language is apoor medium for communicating both
design intent
On Sat, Feb 8, 2014 at 2:57 PM, Quildreen Motta quildr...@gmail.com wrote:
Well, promises are a fairly old concept, with several different
implementations throughout the history of CompSci, and even in JavaScript
land itself. `.chain` itself is not common because it doesn't need to have
On 8 February 2014 12:26, Benjamin (Inglor) Gruenbaum ing...@gmail.comwrote:
On Sat, Feb 8, 2014 at 2:57 PM, Quildreen Motta quildr...@gmail.comwrote:
One of the problems with just following existing solutions is that you'd
also be copying the evolution mistakes and technical debts in those
Sounds both good in principle, and bad like waterfall. Waterfall is dead.
Strike the waterfall part. Still, we end up with three artifacts: a
design goals document, a prototype, and a spec. The design goals should be
the first to stabilize, the spec should be the last.
Would such goals
On Sat, Feb 8, 2014 at 8:11 AM, Kevin Smith zenpars...@gmail.com wrote:
Sounds both good in principle, and bad like waterfall. Waterfall is dead.
Strike the waterfall part. Still, we end up with three artifacts: a
design goals document, a prototype, and a spec. The design goals should be
Resolving this would be much appreciated. Gecko recently turned on
Promises in our nightly builds, and already branched to our aurora
builds. I believe Chrome is in a similar situation.
Chrome has shipped Promises, i.e. they are enabled by default on the
current stable Chrome. So the
On Fri, Feb 7, 2014 at 12:45 PM, Yutaka Hirano yhir...@chromium.org wrote:
Sorry for knowing little about ES consensus, is this the final decision?
Will you change it again?
Yeah, some clarity would be nice.
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=966348 on Gecko
when the news
On 5 February 2014 11:17, Mark S. Miller erig...@google.com wrote:
At the end of Sept mtg, my memory of the state on entry to the meeting
agrees completely with Domenic's. On exit, my memory is
a) We had agreed to promote both the .then level and the .chain level to
ES6. (This is probably the
On 5 February 2014 12:10, Alex Russell slightly...@google.com wrote:
On Wed, Feb 5, 2014 at 12:00 PM, Brendan Eich bren...@mozilla.com wrote:
I'd rather we keep separate and conflict-prone APIs in separate objects,
though. I'd rather we acknowledge that Promises are a library de-facto
However, this question actually triggered me to have a closer look at
the state of the spec (again), the outcome of which was my proposal
for a refactoring. That refactoring based .then on .chain and pulled
it from any of the core logic, thus avoiding the problems you seem to
be alluding
On Fri Feb 7 06:50 AM, Anne van Kesteren wrote:
On Fri, Feb 7, 2014 at 12:45 PM, Yutaka Hirano yhir...@chromium.org wrote:
Sorry for knowing little about ES consensus, is this the final decision?
Will you change it again?
Yeah, some clarity would be nice.
From a user perspective, can
From: es-discuss es-discuss-boun...@mozilla.org on behalf of Jonathan
Bond-Caron jbo...@gdesolutions.com
What seems like a preferred api / pattern from an ecma PoV to serially
execute promises?
Promise.prototype.then
https://github.com/kriskowal/q#sequences
On Fri, Feb 7, 2014 at 8:20 AM, Jonathan Bond-Caron
jbo...@gdesolutions.com wrote:
On Fri Feb 7 06:50 AM, Anne van Kesteren wrote:
On Fri, Feb 7, 2014 at 12:45 PM, Yutaka Hirano yhir...@chromium.org wrote:
Sorry for knowing little about ES consensus, is this the final decision?
Will you
Kevin Smith wrote:
If I may interject some opinions on process...
Sure, it's es-discuss. Plus, you've earned your spurs.
I'm not sure how this fits in with the new post-ES6 process, but from
this one outsider's point of view:
- A formal set of design goals should be completed and agreed
Le 07/02/2014 22:05, Brendan Eich a écrit :
Kevin Smith wrote:
- A *working* implementation should be created and solutions to
real-world use cases should be programmed using the design before any
spec language is authored. Spec-language is a poor medium for
communicating both design intent
David Bruant wrote:
Le 07/02/2014 22:05, Brendan Eich a écrit :
Kevin Smith wrote:
- A *working* implementation should be created and solutions to
real-world use cases should be programmed using the design before
any spec language is authored. Spec-language is a poor medium for
- Promise.cast is renamed to Promise.resolve (remove old Promise.resolve)
- Keep then, reject chain (NOT DEFER, reject!)
- Renaming .cast thus removes over-wrapping (always-wrap) deoptimization
in old Promise.resolve
So basically, since September, we've seen:
- A design proposal which
On 05/02/2014 9.43, Brendan Eich wrote:
Can we regain consensus on the September status quo ante, minus any do
both half-hearted compromises that don't work? Mark, what do you think?
For what it's worth, I've been planning to file a bug on GitHub before
I saw the most recent conclusion, that
On Wed, Feb 5, 2014 at 12:43 AM, Brendan Eich bren...@mozilla.com wrote:
Kevin Smith wrote:
- Promise.cast is renamed to Promise.resolve (remove old
Promise.resolve)
- Keep then, reject chain (NOT DEFER, reject!)
- Renaming .cast thus removes over-wrapping (always-wrap)
On Wed, Feb 5, 2014 at 6:37 AM, Mark S. Miller erig...@google.com wrote:
On Wed, Feb 5, 2014 at 12:43 AM, Brendan Eich bren...@mozilla.com wrote:
Kevin Smith wrote:
- Promise.cast is renamed to Promise.resolve (remove old
Promise.resolve)
- Keep then, reject chain (NOT DEFER,
I can understand the you can't have your cake and eat it too sentiment.
Indeed, I do think that having `.then()` and `.chain()` in the spec is a
mistake. The only thing that saddens me (and this also with some other
parts of the spec, such as Object.create) is that `.then()` is not an
orthogonal
I really regret that I couldn't be there on the last day of the
meeting, and share the frustration I hear in this thread. I honestly
have a hard time viewing this as a consensus, if for nothing else
than that I do not consent. :)
For the record, let me repeat what I wrote in a private
Quildreen Motta wrote:
but as with other parts of JavaScript, the simpler, orthogonal
primitives are not available for users to derive more complex
functionality from easily.
So true. JS is like a mini-toolkit of three-tool Swiss Army Knife
(functions) with constructor and closure tools as
the specialized case.
Best regards,
Ron
-Original Message-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
Brendan Eich
Sent: Wednesday, February 5, 2014 7:46 AM
To: Quildreen Motta
Cc: Mark S. Miller; EcmaScript
Subject: Re: Promise.cast and Promise.resolve
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan
Eich
Kevin Smith wrote:
So basically, since September, we've seen:
- A design proposal which achieved consensus
- A spec implementation which completely ignored that consensus
- And now a third design, which also
Domenic Denicola wrote:
The amount of heat Kevin has piled on to promises-unwrapping, repeatedly, has
been puzzling and unwarranted, but I have chosen mostly to set it aside, as the
words of someone who did not care to understand the whole history and design
constraints involved in writing
On 5 February 2014 18:35, Domenic Denicola dome...@domenicdenicola.com wrote:
The evolution of DOM and ES promises, and the related fragile consensuses,
has been an involved process.
Going back to the source documents, consider what the May AP2 proto-consensus
really is: Abashed Monadic
On Wed, Feb 5, 2014 at 1:34 PM, Andreas Rossberg rossb...@google.com wrote:
On 5 February 2014 18:35, Domenic Denicola dome...@domenicdenicola.com
wrote:
The evolution of DOM and ES promises, and the related fragile consensuses,
has been an involved process.
Going back to the source
On Wed, Feb 5, 2014 at 11:17 AM, Mark S. Miller erig...@google.com wrote:
Unfortunately, just as Yehuda was not there in September and did not agree
to the consensus then, Andreas was not there on Thursday of January and
(above in this thread) does not agree to that consensus. This indicates a
Hi,
Mark wrote:
Unfortunately, just as Yehuda was not there in September and did not
agree to the consensus then, Andreas was not there on Thursday of
January and (above in this thread) does not agree to that consensus.
This indicates a different failure mode we should be concerned about.
Edward O'Connor wrote:
Perhaps TC39 should consider adopting a similar policy.
Policy, schmolicy :-P.
(Presumably clocks with deadlines are required; consensus could break
afterwards, in spite of the formal rules.)
Let's let our hair down a bit and get real here. We did not declare
On Wed, Feb 5, 2014 at 12:00 PM, Brendan Eich bren...@mozilla.com wrote:
Edward O'Connor wrote:
Perhaps TC39 should consider adopting a similar policy.
Policy, schmolicy :-P.
(Presumably clocks with deadlines are required; consensus could break
afterwards, in spite of the formal rules.)
Alex Russell wrote:
I'd rather we keep separate and conflict-prone APIs in separate
objects, though. I'd rather we acknowledge that Promises are a
library de-facto quasi-standard we are trying to codify, not
green-field work where we can start over or do both.
Excited to hear
Tab Atkins Jr. wrote:
Note, though, that you can still have consensus*and* strong
objections. Design-by-committee is still a failure mode to be
avoided.
Excellent point. Argues against do both. Can't ditch .then/resolve
given library code interop constraint. That forces the conclusion from
On Wed, Feb 5, 2014 at 12:17 PM, Brendan Eich bren...@mozilla.com wrote:
Tab Atkins Jr. wrote:
Note, though, that you can still have consensus*and* strong
objections. Design-by-committee is still a failure mode to be
avoided.
Excellent point. Argues against do both. Can't ditch
Tab Atkins Jr. wrote:
(Fixing it does involve magic, or
subclassing, but those are things that can be done internally, rather
than exposed to authors as terrible API.)
Could you say a bit more? Do you mean APIs that defensively hand-box
so the user doesn't have to, with async map and its
On Wed, Feb 5, 2014 at 12:34 PM, Brendan Eich bren...@mozilla.com wrote:
Tab Atkins Jr. wrote:
(Fixing it does involve magic, or
subclassing, but those are things that can be done internally, rather
than exposed to authors as terrible API.)
Could you say a bit more? Do you mean APIs that
Tab Atkins Jr. wrote:
The APIs for Caches and dealing with responses are designed so that
they work nicely together, acting the same way whether you pass a
Response or a PromiseResponse. So you can often respond to requests
with a simple e.respondWith(cache.get('foo')) and it Just Works®.
On Wed, Feb 5, 2014 at 3:51 PM, Brendan Eich bren...@mozilla.com wrote:
Tab Atkins Jr. wrote:
But say you wanted to do something a bit more complicated. For
example, if the cache hits, but the result is a Promise, you might
want to show a throbber until the Promise resolves. Under the old
Just noting that with the infix ! syntax proposed for ES7, this would be
e.respondWith(cache.get('foo') ! [0])
On Wed, Feb 5, 2014 at 4:44 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Feb 5, 2014 at 3:51 PM, Brendan Eich bren...@mozilla.com wrote:
Tab Atkins Jr. wrote:
But say
I really don't know what to do about this.
A few facts:
- Promises have a long history of controversy (I was there on the CommonJS
list!)
- The AP2 design was found acceptable (if not ideal) to all parties,
providing us with a path through the controversy
- Promises were a *very* late
On Tue, Feb 4, 2014 at 11:53 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jan 29, 2014 at 7:33 AM, Kevin Smith zenpars...@gmail.com wrote:
It is, actually, more simplicity. The concept of `Promise.resolve` and
`Promise.chain` is simpler than `Promise.cast` and `Promise.then` (i.e.:
On Tue, Feb 4, 2014 at 10:55 AM, Rick Waldron waldron.r...@gmail.com wrote:
Per Resolution
(https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-01/jan-30.md#conclusionresolution-3)
- Promise.cast is renamed to Promise.resolve (remove old Promise.resolve)
- Keep then, reject chain (NOT
Tab Atkins Jr. wrote:
On Tue, Feb 4, 2014 at 10:55 AM, Rick Waldronwaldron.r...@gmail.com wrote:
Per Resolution
(https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-01/jan-30.md#conclusionresolution-3)
- Promise.cast is renamed to Promise.resolve (remove old Promise.resolve)
Not sure if this is correct, but: This might actually be (perhaps
accidentally) one step closer to allowing promises for thenables in a
cleaner way *if* the need arises in the future.
Since its impossible to create a promise for a promise now, it would be
*theoretically* possible (at some point
Whoops, maybe scratch the monadic part - it would still be impossible to
create a promise for a promise. It would however be possible to protect
thenables.
On Wed, Feb 5, 2014 at 2:17 AM, Gorgi Kosev gorgi.ko...@gmail.com wrote:
Not sure if this is correct, but: This might actually be (perhaps
1. Committee do both / union proposals smell and bloat -- this is a
problem _per se_.
Irony: .then() does both things and there's no way to stop it from doing
both. The do both committee is actually not wanting both, it wants to only
do one thing. We insist, we demand on having a way to NOT do
mfo...@eldergods.com wrote:
#3 is the only point I concede as being even possibly concrete
Then you get a *plonk*, or at least a demeric, for ignoring the very
concrete problem #2: combinators such as .all do not use .chain, they
use .then. Also for ignoring #1 -- it doesn't matter that
Brendan Eich mailto:bren...@mozilla.com
February 4, 2014 at 7:46 PM
Then you get a *plonk*, or at least a demeric,
demerit', of course.
But I'm talking to a fake address. That's pretty bad, it makes me want
to ignore you (*plonk* in USENET terms). Do better quickly, or else
that's the
Wanting something value-ish, featureless, monadic, is a good goal for a
differently named abstraction built on value objects. Promises are not that
abstraction. Do the work to show the win, under a new name (Future?).
I believe the win has already been shown, though: Futures would of course
I like your looking forwards to the future Future, but I really want to
understand the conflict underneath Promises. I'm not trying to selectively
pick issues out, I'm trying to get a general sense for where the conflict
lies that kicked .chain out from complemeting the spec.
The existing
Mark Roberts wrote:
Wanting something value-ish, featureless, monadic, is a good goal
for a differently named abstraction built on value objects.
Promises are not that abstraction. Do the work to show the win,
under a new name (Future?).
I believe the win has already been
mfo...@eldergods.com wrote:
The existing promises library users would be faced with a porting problem
whose size is hard to estimate
Naive go here;
Promise.prototype.then= function(fn){
function recurse(val){
if(val.chain)
val.chain(recurse)
I do believe it meant to say 'cheap words and unreality'. Nothing to care
about.
On Tue, Feb 4, 2014 at 11:04 PM, Brendan Eich bren...@mozilla.com wrote:
mfo...@eldergods.com wrote:
The existing promises library users would be faced with a porting
problem
whose size is hard to
Ryan Scheel wrote:
I do believe it meant to say 'cheap words and unreality'. Nothing to
care about.
Thanks -- makes me not care about replying, you are right!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
On 29 Jan 2014 03:42, Brendan Eich bren...@mozilla.com wrote:
And so we will go with 'chain'.
I assume it has been pointed out before that Underscore/LoDash have
popularised their own chain function/concept?
http://underscorejs.org/#chaining
Hopefully it's distant enough from Promise-world to
While the getMyPromise question wasn't answered yet and still isn't
clear to me, from the other posts I think it can be reworded this way:
```js
var p1 = Promise.resolve(Promise.cast(1));
var p2 = Promise.cast(Promise.cast(1));
```
p1 and p2 will have a different internal state
On 29/01/2014 5.12, Kris Kowal wrote:
In this case, a half pursuit of type purity is a side quest at the
expense of users. Having two ways to resolve and two ways to observe a
promise is unnecessarily confusing. In my experience, one method like
then, that unwraps recursively, and one
to make as many choices. I would argue that it would
make more sense to write `cast` and `then` in terms of `resolve` and
`chain`, however. But this seems to have already been decided.
Answering your previous question:
```js
var p1 = Promise.resolve(Promise.cast(1));
var p2 = Promise.cast
It is, actually, more simplicity. The concept of `Promise.resolve` and
`Promise.chain` is simpler than `Promise.cast` and `Promise.then` (i.e.:
they represent orthogonal concepts, not complected). `Promise.cast` and
`Promise.then` may be, arguably, *easier* to work with, from a user POV,
I have a suggestion about the current draft of the Promises
specification that derives from my experience on the Mozilla code base.
I'm not familiar with how the specification process works, discussion
in this group seemed like a good start.
Those familiar with the subject may find that this
My take is that the difference between cast and resolve is so
subtle that I don't think it captures developer intention. In
other words, if I see some code calling Promise.cast(otherPromise),
I can't be sure that the developer made an intentional choice over
Promise.resolve(otherPromise).
On Tuesday, January 28, 2014 10:13 AM, Kevin Smith zenpars...@gmail.com wrote:
My take is that the difference between cast and resolve is so
subtle that I don't think it captures developer intention. In
other words, if I see some code calling Promise.cast(otherPromise),
I can't be sure that the
That's not true as per the last consensus. There was `Promise.fulfill(p)`
which would've nested promises, but it was left for ES7 to investigate
fulfill+flatMap.
I don't think that statement is correct. Domenic, Allen, Mark, can we get
a ruling? : )
I am hesitant to retread, but I suppose we should clear up the confusion of the
last few messages.
Indeed, things evolved slightly since the last consensus, to the point where
the solution that made the most sense was to store the promise's resolution
value (whatever it may be) then do the
.
For people concerned only about the .then level of abstraction, I see
little reason to ever use Promise.resolve rather than Promise.cast, and
much reason to prefer Promise.cast. But fwiw we did agree to express the
difference now, to be perceived by future and experimental uses of .flatMap
in the future
[Replying here since I'm not sure about how to move the discussion to
the issue tracker without losing the context of Mark's observation.]
On 28/01/2014 20.28, Mark S. Miller wrote:
For people concerned only about the .then level of abstraction, I see
little reason to ever use Promise.resolve
the discussion to
the issue tracker without losing the context of Mark's observation.]
On 28/01/2014 20.28, Mark S. Miller wrote:
For people concerned only about the .then level of abstraction, I see
little reason to ever use Promise.resolve rather than Promise.cast, and
much reason
This accidentally ended up not being forwarded to the list
From: Mark S. Miller [mailto:erig...@google.com]
Sent: 28 January 2014 19:52
To: Forbes Lindesay
Subject: Re: Promise.cast and Promise.resolve
That has always been my preference as well. But given the current stage things
Quildreen Motta wrote:
If that's correct, I don't see any use cases for Promise.resolve right
now, unless a library where to provide a corresponding unspecified
`flatMap` implementation.
IIRC (and I may not; endless promises threads make me sleepy) this is
the reason to have Promise.resolve:
From: es-discuss es-discuss-boun...@mozilla.org on behalf of Brendan Eich
bren...@mozilla.com
Quildreen Motta wrote:
If that's correct, I don't see any use cases for Promise.resolve right now,
unless a library where to provide a corresponding unspecified `flatMap`
implementation.
IIRC
Domenic Denicola wrote:
From: es-discusses-discuss-boun...@mozilla.org on behalf of Brendan
Eichbren...@mozilla.com
Quildreen Motta wrote:
If that's correct, I don't see any use cases for Promise.resolve right now,
unless a library where to provide a corresponding unspecified `flatMap`
1 - 100 of 120 matches
Mail list logo
