Standard builtins' prototypes and toString

[Allen Wirfs-Brock]

On Jun 17, 2014, at 1:41 PM, Till Schneidereit wrote:

> On Tue, Jun 17, 2014 at 6:07 PM, Mark Miller <erights at gmail.com> 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.

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

Allen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140617/433c1a0e/attachment.html>