Standard builtins' prototypes and toString
Till Schneidereit
till at tillschneidereit.net
Thu Jun 12 08:23:26 PDT 2014
On Thu, Jun 12, 2014 at 5:19 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>
wrote:
>
> 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.
>
Good point.
>
> >
> > 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.
>
That's what I was trying to say above, yes. The exact means of the branding
are less important, I think.
>
> 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.
>
Sure. This has always been the case and is, I guess, just a consequence of
how methods work in JS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140612/0f0cc607/attachment.html>
More information about the es-discuss
mailing list