Ѓорѓи Ќосев (2013-12-18T23:32:30.000Z)
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?