Can you leave what you feel is the best solution aside for a moment and
comment on this proposal instead?
Leave aside the best solution - NEVER!!!
: )
2-year old is bugging me, but I'll respond later...
___
es-discuss mailing list
We don't want anti-branding because that puts the burden of proof in
the wrong place. I would only consider it if (a) some kind of branding is
absolutely required, and (b) there is absolutely no other option.
After thinking about it a while longer, I also realized that there would be
nothing
We don't want anti-branding because that puts the burden of proof in
the wrong place.
I forgot to mention this. It should be obvious that the burden of proof is
already in the wrong place, and in the most hostile way possible too (If
you don't want to be treated as a promise, you must not use
By the way, I noticed that duck typing here is *already* not done with
symbols. So the argument isn't its either going to be symbols or nothing.
Its its either going to be symbols or the method then.
That's right, and (digging a little deeper) there are two problems with
using symbols:
1.
On 19 December 2013 23:29, Alex Russell slightly...@google.com wrote:
Right, but number of objects you have to guard with anti-branding is much,
much larger. That argues against thenables pretty strongly, but again, I
don't think we need to change anything for ES6. We can repair this in ES7 if
Thenable assimilation is already used in the wild to a degree that we can't
break. I agree with Alex that we should not re-litigate this. It is only
anti-branding that could be added later -- and only if there's evidence of
a need great enough to justify the added complexity. In the absence of
On 12/20/2013 02:02 PM, Andreas Rossberg wrote:
On 19 December 2013 23:29, Alex Russell slightly...@google.com wrote:
Right, but number of objects you have to guard with anti-branding is
much,
much larger. That argues against thenables pretty strongly, but again, I
don't think we need to
On 12/20/2013 04:38 PM, Kevin Smith wrote:
I highly doubt that will be possible -- experience strongly
suggests that every odd feature _will_ be relied on in the wild by
that time. If we think thenable assimilation is a problem then we
have to remove it now. I, for one, would
Presumably certain promise libraries would try reset the global Promise to
AssimilatingPromise (or whatever) for full parity with polyfilled
environments, which would be fine.
If you're using modules, you wouldn't need to mess with the global object.
You could just import
On 12/20/2013 05:13 PM, Kevin Smith wrote:
Presumably certain promise libraries would try reset the global
Promise to AssimilatingPromise (or whatever) for full parity with
polyfilled environments, which would be fine.
If you're using modules, you wouldn't need to mess with the
True, though if you're using modules like that you won't need thenable
assimilation anyway -- you can count on your code having native promises.
If I understood Alex Russell correctly the core problem is cross-realm
promise polyfillability.
It seems to me we could solve this problem by just
Here is code that breaks with that solution: ``` function
createParser(code) { return {then: chainedTransformation = { ...; return
this; } } } waitForFormSubmit() .then(e = $.get(getUrlFromUrlField()))
.then(code = createParser(code, options)) ```
Not necessarily - if you're using new DOM
Not necessarily - if you're using new DOM APIs which
return promises, then you need to upgrade your libraries.
Libraries are easy to upgrade. A crummy legacy is not.
Okay, so how will end users or jQuery authors upgrade their promises to
become ES6-compliant?
On Fri, Dec 20, 2013 at 5:45
On Fri, Dec 20, 2013 at 12:38 PM, Kevin Smith zenpars...@gmail.com wrote:
Okay, so how will end users or jQuery authors upgrade their promises to
become ES6-compliant?
I don't know enough about jQuery's internals to write convincing code, but
the basic idea is that you feature detect for
jQuery was just an example.
The basic idea is that you feature detect for ES6 Promises. If that test
passes, then you implement jQuery.Deferred using a Promise subclass (which
would do assimilation for backward compatibility reasons). Otherwise you
implement it the old-fashioned way.
Hold on
On Fri, Dec 20, 2013 at 5:02 AM, Andreas Rossberg rossb...@google.comwrote:
On 19 December 2013 23:29, Alex Russell slightly...@google.com wrote:
Right, but number of objects you have to guard with anti-branding is
much,
much larger. That argues against thenables pretty strongly, but again,
Hold on there. If they already do assimilation, why would you even
inherit?
So that the system will see jQuery's assimilating promises as real promises.
So you're saying that promise library authors should rearchitect their
entire libraries, and that solution is better than them just
On Fri, Dec 20, 2013 at 12:24 PM, Gorgi Kosev gorgi.ko...@gmail.com wrote:
Not necessarily - if you're using new DOM APIs which
return promises, then you need to upgrade your libraries.
Libraries are easy to upgrade. A crummy legacy is not.
Okay, so how will end users or jQuery authors
On Thu 19 Dec 2013 07:42:31 AM CET, Andrea Giammarchi wrote:
The only thing that does is having *one*, *standard* contract -- and we are
past due on that.
Perhaps the right path would be to try and discuss this for
Promises/A++, and maybe if it happens there, ES7 afterwards :)
Devs also
I think this anti-branding idea is worth considering, but using a symbol or
weakmap for the anti-branding rather than a magic double-underbar property
name. Unlike prior positive thenable branding proposals, this one doesn't
break existing code but still provides systems that use then in contrary
On Thu 19 Dec 2013 06:24:50 PM CET, Mark S. Miller wrote:
I think this anti-branding idea is worth considering, but using a
symbol or weakmap for the anti-branding rather than a magic
double-underbar property name. Unlike prior positive thenable branding
proposals, this one doesn't break
On Thu, Dec 19, 2013 at 9:24 AM, Mark S. Miller erig...@google.com wrote:
I think this anti-branding idea is worth considering, but using a symbol
or weakmap for the anti-branding rather than a magic double-underbar
property name. Unlike prior positive thenable branding proposals, this one
...but only in an unpolyfillable, ES6-only world.
Right, they don't help existing libraries, but it would still pave a path
towards branded-only promises in the (unfortunately very, very far) future
(with ES5 all but gone)
Only ghetto anti-branding will help existing libraries (and make it
Right, but number of objects you have to guard with anti-branding is much,
much larger. That argues against thenables pretty strongly, but again, I
don't think we need to change anything for ES6. We can repair this in ES7
if it's a problem in practice.
On Thu, Dec 19, 2013 at 2:21 PM, Gorgi
On Wed, Dec 18, 2013 at 3:32 PM, Ѓорѓи Ќосев gorgi.ko...@gmail.com wrote:
I understand that adding branding to promises is impossible at this
point, as it would break backward compatibility with all existing
implementations.
That wasn't the overriding consdieration. I don't care if we don't
On 18 Dec 2013 18:20, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
Alex can I ask you if there's any specific deadline you are talking about?
Promises aren't important. They are a tool. And the design space is
*clearly* overconstrained. Anyone paying attention can see that. We should
On 12/19/2013 02:56 AM, Alex Russell wrote:
On Wed, Dec 18, 2013 at 3:32 PM, Ѓорѓи Ќосев gorgi.ko...@gmail.com
mailto:gorgi.ko...@gmail.com wrote:
I understand that adding branding to promises is impossible at this
point, as it would break backward compatibility with all existing
On 18 Dec 2013 20:27, Ѓорѓи Ќосев gorgi.ko...@gmail.com wrote:
On 12/19/2013 02:56 AM, Alex Russell wrote:
On Wed, Dec 18, 2013 at 3:32 PM, Ѓорѓи Ќосев gorgi.ko...@gmail.com
wrote:
I understand that adding branding to promises is impossible at this
point, as it would break backward
Thanks for the clarification and FWIW, yeah ... I agree with you but I also
appreciate the effort everyone is putting trying to bring new features that
are as platform agnostic as possible ... but then again, we have real
life/devs/code screaming for solutions ASAP
Devs also complain about
On Thu, Oct 10, 2013 at 3:39 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Thu, Oct 10, 2013 at 6:26 PM, David Bruant bruan...@gmail.com wrote:
Hi,
The question of thenables came back on Mozilla's Bugzilla [1] (see
comment 29 30) with a decent share of skepticism that I share too.
30 matches
Mail list logo
