Subclassing ES6 objects with ES5 syntax.

C. Scott Ananian ecmascript at cscott.net
Tue Apr 28 19:31:28 UTC 2015


On Tue, Apr 28, 2015 at 2:41 PM, Allen Wirfs-Brock <allen at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150428/695177a3/attachment.html>


More information about the es-discuss mailing list