Standard builtins' prototypes and toString

[Allen Wirfs-Brock]

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