I really regret that I couldn't be there on the last day of the meeting, and share the frustration I hear in this thread. I honestly have a hard time viewing this as a "consensus", if for nothing else than that I do not consent. :)
For the record, let me repeat what I wrote in a private conversation with Brendan the other day: "This destroys the fragile consensus we had built last May, on which my and others' consent to moving forward with the spec work had been based since then. I am deeply concerned how a strategy of (largely) ignoring that consensus and creating a different precedent instead has been successful here. I don't buy the over-wrapping argument. I doubt it will be an issue in practice, for the same reason that recursive unwrapping is rarely needed in practice. The committee is prematurely optimising for the odd case out that can always be avoided by [careful] design. On the other hand, I'm far more concerned about the cost that the unwrapping and thenable-assimilation machinery imposes on the _common_ case, and which can _not_ be avoided (lacking .chain). A [separate] library would be dead on arrival, especially since the DOM and other libraries won't use it. It wouldn't even allow you to hygienicly wrap them, since you'd always have to go through the tainted operations. Anyway, we've discussed this briefly in the V8 team and decided to keep the .chain method in V8. We've heard enough voices, from inside and outside Google, who dislike the spec'ed API and much rather use chain. Unfortunately, you cannot polyfill it... " To add to that, I don't view the "double functionality" as a serious issue either. Chain is the (compositional) primitive, .then is a convenience abstraction on top. We have plenty of those in the lib. /Andreas _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
