> 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 "temporary" about anti-branding. Library authors will likely have
to support ES6 for quite a while, therefore after flipping the switch,
everyone will be stuck doing both branding and anti-branding -- promise
library authors doing the first for ES7+, others doing the second for ES6.

> The problem with "branding" in general is that TC39 has decided, for
better or worse, that duck-typing of this kind is going to be done with
symbols.  And symbols aren't really pollyfillable.

I agree - that seems to be the core issue. Why was this decided? Can
someone please point me to the relevant thread(s) that I could read?

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". The fact that
Promises already break the rule is a sign that its probably a bad decision,
at least for things that benefit from polyfills. So yeah, I'd definitely
like to read more.



On Sat, Dec 21, 2013 at 2:20 PM, Kevin Smith <zenparsing at gmail.com> wrote:

>
> Can you leave what you feel is the best solution aside for a moment and
>>> comment on this proposal instead?
>>
>>
>>
> 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.
>
> The problem with "branding" in general is that TC39 has decided, for
> better or worse, that duck-typing of this kind is going to be done with
> symbols.  And symbols aren't really pollyfillable.
>
> My recommendation to TC39 would be to remove thenable coercion from the
> Promise design and inform library authors that they need to subclass the
> Promise type if available.  If it turns out that library authors are unable
> to do so, then add coercion back to the design.
>
> This research can be done within a couple of weeks, I would think.
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131221/e08667cd/attachment-0001.html>

> 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 "temporary" about anti-branding. Library authors will likely have
to support ES6 for quite a while, therefore after flipping the switch,
everyone will be stuck doing both branding and anti-branding -- promise
library authors doing the first for ES7+, others doing the second for ES6.

> The problem with "branding" in general is that TC39 has decided, for better or worse, that duck-typing of this kind is going to be done with symbols.  And symbols aren't really pollyfillable.

I agree - that seems to be the core issue. Why was this decided? Can
someone please point me to the relevant thread(s) that I could read?

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". The fact that
Promises already break the rule is a sign that its probably a bad decision,
at least for things that benefit from polyfills. So yeah, I'd definitely
like to read more.