On Tue, Apr 28, 2015 at 2:41 PM, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote:
> So, ES6 Promises reflect a specific set of design decisions, including a > specific definition of "same type" that appears to exist solely for use by > Promise.resolve. All that design guarantees is that the object has an > certain specific internal slot whose value is tested in a specific way by > Promise.resolve. It doesn't guarantee that the object is a well-promise or > that it has any specific other characteristics that are expected of Foo > objects. It's hard to extrapolate from that specific design to the > underlying intent of the designer. > I think this is exactly my point. I understand what the original intent was, but the result is (it seems to me) a wart. `Promise.resolve` now uses its own idiosyncratic definition for "same type" which isn't shared by any other JavaScript objects. What's more, it's not clear that its idiosyncratic definition actually accomplishes what it was meant to. It seems to me that this is an incomplete feature that should have been dropped from the spec. I apologize for not noticing this sooner. Folks who want some sort of "tamper-proof" Promises should probably build them in user-space on top of the other abstractions which are provided. --scott ps. I note that `core-js`/`babel` have already implemented the fix I proposed above, of looking at the prototype chain instead of [[PromiseConstructor]]: https://github.com/zloirock/core-js/blob/v0.9.4/modules/es6.promise.js#L194
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
