On 12/20/2013 02:02 PM, Andreas Rossberg wrote:
> On 19 December 2013 23:29, Alex Russell <slightlyoff at 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
>> it's a problem in practice.

Will this be shimmable (by monkey patching) in ES6 in a way that enables
all promises (even those produced by the DOM) to have the new behavior?

The objects you have to guard with anti-branding are only those who have
a .then method and are not promises. True, its nowere nearly good as
branding. However, its still better than making ".then" a complete
taboo. At least the library authors get *some* say on the matter.

This is how I imagine things happening:

Lets say the anti-branding property is called "convertableToPromise" and
that the value "true" is assumed if the property is not defined on the
thenable.

Lets just not even call it anti-branding - its just a marker.

Example 1:

A library author that is not very familiar with all the intricacies of
promises writes a code parsing/transformation library that uses .then as
a method of chaining different transformations. It turns out to be
widely popular, and a library user wants to create a parser for remotely
downloaded code. The library user fires a download operation and gets a
promise, creates a transformed promise by adding a .then callback, and
attempts to return the parser from within the then callback. Everything
breaks.

Solutions available without anti-branding:

- the author of the library must rename .then and must tell every single
person depending on that library to refactor to the new method
- the author declares the library incompatible with promises.

note: A lint tool *cannot* reliably warn them about it, because it
cannot tell whether they want thenable assimilation or not (whether the
class they are writing represents a "promise" or not)

Solution available with anti-branding
- the author of the library adds `Parser.prototype.convertableToPromise
= false;`. Everything starts working.

Even better, the library user can also likely do this.

note: A lint tool can warn them about it before the library becomes
popular, avoiding the troublesome situation in the first place.


Example 2:

A library author wants to write a library for a new kind of functional
asynchrony abstraction. They actually *do* want promises to be able to
assimilate this asynchrony, so they add a method called .then. Since
they are quite familiar with asynchronous code (and therefore likely
with promises) they know that even though they don't have to, they can add:

`Asynchrony.prototype.convertableToPromise = true;`

to explicitly state that this object is infact convertable to a promise.
A lint tool or an IDE can even warn them about it and they will add it
to make the tool stop complaining.


Hopeful far future outcome:

ES7 arrives. Most promise libraries inherit from the built-in Promise,
and the semantics of `convertableToPromise` are well understood by those
who write async code. Therefore its possible to test whether its okay to
flip the default value of `thenable.convertableToPromise` to false. If
its determined that this would cause too much breakage at that
particular moment, the decision is postponed again for ES8.

If at any point its determined that its possible to flip this switch,
the "thenable wart" will be forever removed from the language.

>
> 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 welcome that. We could still provide an
> _explicit_ thenable adaptor method in the Promise API.

But this will make promises created by existing promise libraries
incompatible with built-in promises. It will cause the same problem, but
in reverse. Yes, hopefully library authors will add the branding to
their promise libraries, and hopefully after a while everything will
start working except legacy code, but its still a worse outcome.

That is why I proposed anti-branding - as a compromise.

On 12/20/2013 02:02 PM, Andreas Rossberg wrote:
> On 19 December 2013 23:29, Alex Russell <slightlyoff at 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
>> it's a problem in practice.

Will this be shimmable (by monkey patching) in ES6 in a way that enables
all promises (even those produced by the DOM) to have the new behavior?

The objects you have to guard with anti-branding are only those who have
a .then method and are not promises. True, its nowere nearly good as
branding. However, its still better than making ".then" a complete
taboo. At least the library authors get *some* say on the matter.

This is how I imagine things happening:

Lets say the anti-branding property is called "convertableToPromise" and
that the value "true" is assumed if the property is not defined on the
thenable.

Lets just not even call it anti-branding - its just a marker.

Example 1:

A library author that is not very familiar with all the intricacies of
promises writes a code parsing/transformation library that uses .then as
a method of chaining different transformations. It turns out to be
widely popular, and a library user wants to create a parser for remotely
downloaded code. The library user fires a download operation and gets a
promise, creates a transformed promise by adding a .then callback, and
attempts to return the parser from within the then callback. Everything
breaks.

Solutions available without anti-branding:

- the author of the library must rename .then and must tell every single person depending on that library to refactor to the new method
- the author declares the library incompatible with promises.

note: A lint tool *cannot* reliably warn them about it, because it
cannot tell whether they want thenable assimilation or not (whether the
class they are writing represents a "promise" or not)

Solution available with anti-branding
- the author of the library adds `Parser.prototype.convertableToPromise = false;`. Everything starts working.

Even better, the library user can also likely do this.

note: A lint tool can warn them about it before the library becomes
popular, avoiding the troublesome situation in the first place.


Example 2:

A library author wants to write a library for a new kind of functional
asynchrony abstraction. They actually *do* want promises to be able to
assimilate this asynchrony, so they add a method called .then. Since
they are quite familiar with asynchronous code (and therefore likely
with promises) they know that even though they don't have to, they can add:

`Asynchrony.prototype.convertableToPromise = true;`

to explicitly state that this object is infact convertable to a promise.
A lint tool or an IDE can even warn them about it and they will add it
to make the tool stop complaining.


Hopeful far future outcome:

ES7 arrives. Most promise libraries inherit from the built-in Promise,
and the semantics of `convertableToPromise` are well understood by those
who write async code. Therefore its possible to test whether its okay to
flip the default value of `thenable.convertableToPromise` to false. If
its determined that this would cause too much breakage at that
particular moment, the decision is postponed again for ES8.

If at any point its determined that its possible to flip this switch,
the "thenable wart" will be forever removed from the language.

> 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 welcome that. We could still provide an
> _explicit_ thenable adaptor method in the Promise API.

But this will make promises created by existing promise libraries
incompatible with built-in promises. It will cause the same problem, but
in reverse. Yes, hopefully library authors will add the branding to
their promise libraries, and hopefully after a while everything will
start working except legacy code, but its still a worse outcome.

That is why I proposed anti-branding - as a compromise.