On 12/19/2013 02:56 AM, Alex Russell wrote:
> On Wed, Dec 18, 2013 at 3:32 PM, Ѓорѓи Ќосев <gorgi.kosev at gmail.com
> <mailto:gorgi.kosev at 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
> have a-priori compatibility. The bigger issue is the lack of symbol
> infrastructure in the language and the inability to polyfill if we do.
> I've long argued for "ghetto branding" (something less foot-gun-ish
> than an extractable then callable), but in the interest of harmony,
> was not willing to fight for the better design at the end.
>
This doesn't need symbols at all, and it could be considered a "bugfix"
addition - there is still time for those, I believe?
 
It would make `.then` in the method name position less of a language
keyword. Without breaking compatibility with existing implementations.
It will also pave the path towards a future where most implementations
inherit from built in promises and those that don't set their
`prototype.__notPromise__ = false`,

If (and when) such a future arrives, the switch can be potentially
flipped to assume `true` instead of `false`, thereby essentially
removing the quirk from the language - completely.

> Our primary goal here needs to be shipping something ASAP. All other
concerns are, in the scheme of things, irrelevant.'
>
> We're already half a year late on this.

Should the language really ban all objects from using `.then`, forever?
Should it force library authors to face the decision:

- my objects remain incompatible with promises (cannot be returned by
them), or
- rename `.then` method, do a massive refactor, also force all my users
to do a massive refactor

Why not provide a harmless third option?

- add __notPromise__ flag to my prototype to tell promises not to
assimilate these objects

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131219/1bdc9c5f/attachment.html>

On 12/19/2013 02:56 AM, Alex Russell wrote:
> That wasn't the overriding consdieration. I don't care if we don't
> have a-priori compatibility. The bigger issue is the lack of symbol
> infrastructure in the language and the inability to polyfill if we do.
> I've long argued for "ghetto branding" (something less foot-gun-ish
> than an extractable then callable), but in the interest of harmony,
> was not willing to fight for the better design at the end.

This doesn't need symbols at all, and it could be considered a "bugfix"
addition - there is still time for those, I believe?
 
It would make `.then` in the method name position less of a language
keyword. Without breaking compatibility with existing implementations.
It will also pave the path towards a future where most implementations
inherit from built in promises and those that don't set their
`prototype.__notPromise__ = false`,

If (and when) such a future arrives, the switch can be potentially
flipped to assume `true` instead of `false`, thereby essentially
removing the quirk from the language - completely.

> Our primary goal here needs to be shipping something ASAP. All other concerns are, in the scheme of things, irrelevant. We're already half a year late on this.

Should the language really ban all objects from using `.then`, forever?
Should it force library authors to face the decision:

- my objects remain incompatible with promises (cannot be returned by them), or
- rename `.then` method, do a massive refactor, also force all my users to do a massive refactor

Why not provide a harmless third option?

- add `__notPromise__` flag to my prototype to tell promises not to
assimilate these objects