> 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 the generic
method name .then. Don't use then, or you will be assimilated. Resistance
is futile).

Anti-branding is indeed crappy and hacky and not really temporary, but it
does make resistance possible...



On Sat, Dec 21, 2013 at 4:41 PM, Gorgi Kosev <gorgi.kosev at gmail.com> wrote:

> > 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/dbed1a23/attachment.html>

> 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 the generic
method name .then. Don't use then, or you will be assimilated. Resistance
is futile).

Anti-branding is indeed crappy and hacky and not really temporary, but it
does make resistance possible...