On Thu 19 Dec 2013 06:24:50 PM CET, Mark S. Miller wrote: > I think this anti-branding idea is worth considering, but using a > symbol or weakmap for the anti-branding rather than a magic > double-underbar property name. Unlike prior positive thenable branding > proposals, this one doesn't break existing code but still provides > systems that use "then" in contrary ways an ability to cope. It also > doesn't break anything premised on the promise-unwrapping consensus > that we've agreed on and specced.
Thanks :) > I see only two questions: > > * Whether the benefit is worth the additional complexity? > * If we do decide to do this, does it make sense to postpone it to ES7? > > Unless there is significant demonstrated need, I am leaning away from > the paying the additional complexity. This anti-branding proposal is not just about making the immediate future smoother. My hope is that it could potentially provide a path for the far future where research can be done to determine whether compatibility issues are still there. If they aren't, Promises could start assuming that object[notPromiseSymbol] === true, (unless explicitly stated otherwise). This practically means completely removing the wart from the language except for promise authors that don't extend the built-in Promise (or for those that actually *want* automatic thenable assimilation of their non-promises) I feel that right now the `then` method is a bit worse than a keyword. Unlike keywords, it may cause random hard to find bugs and unpredictable behaviour (instead of syntax errors) for unsuspecting users. That makes any path that can potentially make it unreserved worth pursuing, at any time (now or in the future). The complexity cost is not much greater than regular branding for implementers. The complexity cost is not much greater for end-users either - in both cases they will still have to know that `.then` is special (albiet in the latter case case, still available, and potentially not special at all in the future). And in the latter case, cognitive load can potentially be reduced for users. Its easier to make a static analysis tool that warns them to explicitly set this[notPromiseSymbol] to either true or false when a then method is detected. Whereas without the anti-brand, the tool would have no idea whether the user really wants automatic assimilation, or they're just unaware of the special behaviour. > OTOH, since this would mainly be > about mitigating the pain of fixing contrary uses of "then", if we're > going to do it at all, we should do it in ES6. Right - thats why I tried suggesting it now... But still, I think that there are enough reasons to do this even if after the ES6 ship sails. > If we don't, then these contrary uses of "then" will probably already be > fixed by the time ES7 rolls out. I'm sorry, but I cannot accept the claim that there is such a thing as "contrary use of then". Libraries are not at fault here - ES6 is the one trampling on their use of a perfectly valid, very generic method name. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
