On Jun 12, 2014, at 5:26 AM, Till Schneidereit wrote:
> While working on changing Date.prototype to be a plain object in
> SpiderMonkey, we realized that there's an issue: the way things are specced
> now, `alert(Date.prototype)` will throw, because `Date.prototype.toString`
> isn't generic. The same applies for all builtins with non-generic `toString`
> prototype functions.
Fortunately there aren't very many of those. I think it is only Date and RegExp
that have this issue among the ES6 built-ins
>
> To resolve this, I propose changing these `toString` to first check if the
> `this` value is %FooPrototype% (e.g., %DatePrototype% in the case at hand)
> and return the result of the equivalent of calling the original
> Object.prototype.toString.
that breaks if you move such methods across Realms.
>
> I'm not sure if that is enough to cover subclasses of these builtins. Will
> calling `toString` on the prototype of `class MyDate extends Date{}` still
> throw? If so, that would at least not be a backwards-compatibility concern,
> but it's probably also not desirable.
Yes, it would still throw for subclasses.
I think the pattern we should follow for such built-in toString methods is that
if a branding check of this sort is performed, the fall back should be to
perform the built-in Object.prototype.toString behavior rather than throwing.
Unless somebody sees issues with this fix, I'll incorporate it into the spec.
for Date and RegExp.
Of course, even with this fix there is no guarantee that invoking toString on
an object won't throw. Debugging tool that expect to use toString need to take
that into account and provide their own fallbacks.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
