Standard builtins' prototypes and toString

Till Schneidereit till at
Wed Jun 18 01:00:38 PDT 2014

On Tue, Jun 17, 2014 at 11:27 PM, Allen Wirfs-Brock <allen at>

> On Jun 17, 2014, at 1:41 PM, Till Schneidereit wrote:
> On Tue, Jun 17, 2014 at 6:07 PM, Mark Miller <erights at> wrote:
>> I am happy with #b as well, though I prefer #c. I also agree with C.
>> Scott's interpretation of #c, to mean, appropriate degenerate value, which
>> is generally the zero value, but is plausibly NaN for Date.
>> Whichever experiment Nightly tries first with a positive outcome, I
>> expect that's what we'll do, since the difference between #b and #c is not
>> large enough to be worth waiting for a second experiment.
> I don't much care which one we choose, to be honest. I kinda doubt that #b
> will have more compatibility issues than #c[1], and find conceptually
> cleaner by a thin margin: a non-Date object isn't an invalid Date, it's not
> a Date. But then again, if you don't want an object to be treated as a
> Date, don't call Date's toString on it? Implementation-wise, it's pretty
> much a wash, at least.
> I think the most important thing to test is changing Date.prototype to be
> a non-date (and for that matter changing all the other legacy built-ins
> that have changed to non-instances). That's the big bet and we should get
> feedback on.


> As far as I can tell, toString being an issue is just a conjecture that
> hasn't been tested. So, you could even go ahead an implement the
> corresponding toString methods as currently stands in the ES6 spec. (throw
> for the wrong kind of object) which probably requires no change to their
> current implementation.

I'm somewhat opposed to this for two reasons:

One is that I'm pretty sure that it won't be compatible, whereas I'm
optimistic about making Date.prototype a non-Date. There are tens of
thousands of people using Nightly as their default browser, and while that
makes it a good first target for experiments like this, it also means that
we shouldn't do experiments where we're not optimistic about the outcome.

The other is that I still think the standard library shouldn't contain
objects that throw when they're string-ified or value-ified.

> If we run into an actual toString issue we will have a better idea of
> which fix may be preferable.

How is that? The script-visible differences between #b and #c would mostly
be that Date.prototype.toString would return "[Object Date]" for #b and (as
it does now) "Invalid Date" for #c. It's not clear to me how testing the
spec status quo would give us any more information about which one of these
would be more compatible or preferable on other grounds.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list