Standard builtins' prototypes and toString

[Brendan Eich]

I held back but can't any longer.

Till Schneidereit wrote:
>
>
>     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.

Agreed on both points.

Changing Date.prototype from how it has stringified for (now) over 19 
years [1] takes unknown probabiltiy times non-trivial cost risk, and 
Firefox Nightly won't be enough to find the content that breaks (sorry). 
Other engines would need to test and even put into release channels the 
change, and then we'd hope some smart site bug diag guru figures out the 
problem, if there is a problem.

Best way to avoid this is to avoid it. What's the profit in (b)?

>
>     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]"

(Lower-case "object" there.)

> 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.

Just use "Invalid Date" and get on with more important work. My 2 cents.

/be

[1] SpiderMonkey session:

js> Date.prototype.toString()
"Invalid Date"
js> Date.prototype.toSource()
"(new Date(NaN))"