Ѓорѓи Ќосев (2013-12-18T23:32:30.000Z)
I understand that adding branding to promises is impossible at this
point, as it would break backward compatibility with all existing
implementations.

However, thenable assimilation could still be made slightly less sad by
doing something very similar to branding, without breaking backward
compatibility.

The assimilation procedure could check if the thenable has a property
that brands it non-assimilatable, e.g. __notPromise__ If such a property
exists and is set to true, it will not assimilate it.

While far from perfect, this will at least allow objects from existing
libraries that have a .then method to coexist with promises without
forcing library authors (and users) to massively refactor their code.
Authors would only need to add the flag __notPromise__ to their
prototypes - all other existing code will continue to work normally.

I believe this would be better than globally banning such a generic name
like `.then` as a method.

As a bonus, statis analysis tools could possibly warn users to
explicitly add `__notPromise__ = false;` (i.e. they could advise users
to explicitly express intent WRT to assimilation)

Does this sound like a good idea?
domenic at domenicdenicola.com (2014-01-03T16:54:19.661Z)
I understand that adding branding to promises is impossible at this
point, as it would break backward compatibility with all existing
implementations.

However, thenable assimilation could still be made slightly less sad by
doing something very similar to branding, without breaking backward
compatibility.

The assimilation procedure could check if the thenable has a property
that brands it non-assimilatable, e.g. `__notPromise__` If such a property
exists and is set to true, it will not assimilate it.

While far from perfect, this will at least allow objects from existing
libraries that have a .then method to coexist with promises without
forcing library authors (and users) to massively refactor their code.
Authors would only need to add the flag `__notPromise__` to their
prototypes - all other existing code will continue to work normally.

I believe this would be better than globally banning such a generic name
like `.then` as a method.

As a bonus, statis analysis tools could possibly warn users to
explicitly add `__notPromise__ = false;` (i.e. they could advise users
to explicitly express intent WRT to assimilation)

Does this sound like a good idea?