Oliver Hunt pointed out the bug in SpiderMonkey's implementation (in
Firefox 3.5) of Object.getPrototypeOf, where a primitive value does
not cause a TypeError to be thrown as specified in ES5 draft. This bug
was based on some miscommunication [1] and it will be fixed ASAP [2].
Throwing on non-Object (Object the spec type, not only instances of
the Object native constructor) is as specified for all of the new
Object metaprogramming APIs. But throwing differs from the behavior on
primitives of the three ES3 Object.prototype additions,
hasOwnProperty, getPrototypeOf, and propertyIsEnumerable, which
convert |this| using the ToObject spec-internal helper function.
I bring this up not to lobby for a change to ES5 as drafted, just to
note the inconsistency. This came up at a TC39 meeting a while ago and
my notes say the committee was willing to use ToObject for
getPrototypeOf, but the change was not made. Again, probably for the
best.
It would be great in Harmony to remove more of the Java-inspired
primitive type "specialness", compatibly if possible but in stricter
strict mode if necessary. I'm not sure how to do it in a way that
helps getPrototypeOf, but even without a specific proposal, it helps
to note that it's easier to relax an error condition in the future
than to try to impose one.
So again, no ES5 change needed, just discussion fodder.
Oliver Hunt pointed out the bug in SpiderMonkey's implementation (in
Firefox 3.5) of Object.getPrototypeOf, where a primitive value does
not cause a TypeError to be thrown as specified in ES5 draft. This bug
was based on some miscommunication [1] and it will be fixed ASAP [2].
Throwing on non-Object (Object the spec type, not only instances of
the Object native constructor) is as specified for all of the new
Object metaprogramming APIs. But throwing differs from the behavior on
primitives of the three ES3 Object.prototype additions,
hasOwnProperty, getPrototypeOf, and propertyIsEnumerable, which
convert |this| using the ToObject spec-internal helper function.
I bring this up not to lobby for a change to ES5 as drafted, just to
note the inconsistency. This came up at a TC39 meeting a while ago and
my notes say the committee was willing to use ToObject for
getPrototypeOf, but the change was not made. Again, probably for the
best.
It would be great in Harmony to remove more of the Java-inspired
primitive type "specialness", compatibly if possible but in stricter
strict mode if necessary. I'm not sure how to do it in a way that
helps getPrototypeOf, but even without a specific proposal, it helps
to note that it's easier to relax an error condition in the future
than to try to impose one.
So again, no ES5 change needed, just discussion fodder.
/be
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=444787#c7
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=509510
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090810/8061b9af/attachment.html>
Oliver Hunt pointed out the bug in SpiderMonkey's implementation (in
Firefox 3.5) of Object.getPrototypeOf, where a primitive value does
not cause a TypeError to be thrown as specified in ES5 draft. This bug
was based on some miscommunication [1] and it will be fixed ASAP [2].
Throwing on non-Object (Object the spec type, not only instances of
the Object native constructor) is as specified for all of the new
Object metaprogramming APIs. But throwing differs from the behavior on
primitives of the three ES3 Object.prototype additions,
hasOwnProperty, getPrototypeOf, and propertyIsEnumerable, which
convert |this| using the ToObject spec-internal helper function.
I bring this up not to lobby for a change to ES5 as drafted, just to
note the inconsistency. This came up at a TC39 meeting a while ago and
my notes say the committee was willing to use ToObject for
getPrototypeOf, but the change was not made. Again, probably for the
best.
It would be great in Harmony to remove more of the Java-inspired
primitive type "specialness", compatibly if possible but in stricter
strict mode if necessary. I'm not sure how to do it in a way that
helps getPrototypeOf, but even without a specific proposal, it helps
to note that it's easier to relax an error condition in the future
than to try to impose one.
So again, no ES5 change needed, just discussion fodder.
/be
[1] bugzilla.mozilla.org/show_bug.cgi?id=444787#c7 [2] bugzilla.mozilla.org/show_bug.cgi?id=509510