On Tue, Jun 17, 2014 at 11:27 PM, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote:
> > On Jun 17, 2014, at 1:41 PM, Till Schneidereit wrote: > > On Tue, Jun 17, 2014 at 6:07 PM, Mark Miller <erig...@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. > Agreed. > > 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.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
