Standard builtins' prototypes and toString

Till Schneidereit till at
Thu Jun 12 12:06:45 PDT 2014

On Thu, Jun 12, 2014 at 8:29 PM, C. Scott Ananian <ecmascript at>

> On Thu, Jun 12, 2014 at 12:59 PM, Allen Wirfs-Brock
> <allen at> wrote:
> > So, I think the current spec. best matches our consensus about changing
> > these prototypes to non-consructor instances.  I think my proposed
> > alternative toString fall back pattern is more useful, but is a bigger
> > breaking change. Are we willing to up the bet, or should we let it ride
> as
> > is?
> Just restating and naming the alternatives:
> (a) `#toString` throws TypeError when given a non-instance.  Changes
> `Date#toString()`, no change to `{})`.
> (b) `#toString` is generic; invokes `Object#toString` when given a
> non-instance.  Changes both `Date#toString()` and
> `{})`.
> (c) `#toString` is generic; uses a "zero" value when given a
> non-instance.  No change to `Date#toString()`; changes
> `{})`.
> (d) `#toString` returns a "zero" value when given a prototype, throws
> TypeError otherwise. No change to `Date#toString()` or
> `{})`.
> Option (a) is what is in the current spec.
> Options (b) and (c) make the `toString` method generic.
> Option (d) preserves compatibility to the greatest degree possible.

There is (e) `#toString` returns "[object Object]" when invoked on the (an)
original Date.prototype (regardless of the Realm it came from). Otherwise,
it throws when invoked on a non-instance.

This is what Allen and me proposed. And I think it's the best solution for
two reasons:
- I'd bet good money that (a) breaks the web so just isn't an option.
- as Jason points out, stringifying an object should succeed for as many
things as possible. The script authors can do what they want, but the
builtins shouldn't throw if you stringify them.

As André points out, this affects `valueOf`, too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list