Standard builtins' prototypes and toString

[Allen Wirfs-Brock]

On Jun 17, 2014, at 2:10 AM, Till Schneidereit wrote:

> On Thu, Jun 12, 2014 at 10:42 PM, C. Scott Ananian <ecmascript at cscott.net> wrote:
> On Thu, Jun 12, 2014 at 3:56 PM, Mark S. Miller <erights at google.com> wrote:
> > I like this list. I prefer #c.
> > * We have previously succeeded at making previously non-generic methods
> > generic. I think we could get away with #c.
> > * It is easier for a normal JS programmer to do the equivalent of #c for
> > most of their classes.
> 
> FWIW, if a change to the spec is needed, I also favor (c).
> 
> Both generic options (b) and (c) have consistent behavior that can
> extend to `#valueOf`.  In option (b) you would presumably invoke
> `Object#valueOf`  and for option (c) you'd return the "zero" value.
> 
> Is this close-ish to a consensus? If so, we'd implement and land it on Nightly to get an idea of its web compatibility. It doesn't sound like there's a meaningful danger of implementing something seriously incompatible with what the spec is going to say - if (c) is roughly adopted.

I'm not sure who introduced the idea that the Date.prototype should have a "zero value", but that is inconsistent with ES3&5 where the TimeValue of Date.prototype is NaN: http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.5 If we went the (c) route it should presumably be modified to use NaN and not 0.

I have yet seen any evidence that there is an issue with valueOf.  The original premise that TC39 agreed to is that we would make prototypes ordinary objects except for cases (like Array and Function) where there were known dependency on the legacy instance behavior.  Has anybody actually observed code that depends upon  Date.prototype.valueOf() returning NaN?

I'm also, not sure that we've seen an actual real world case that depends upon Date.prototype.toString() not throwing but I'm very sympathetic to the argument that it should be possible to toString any object.

That suggests that the issue here is broader than just legacy compatability for Date.prototype.toString. We have lots of new built-in constructors (Map, for example) whose prototypes are not instance objects.  As of now we haven't defined specialized toString methods for them, but we might in the future and it would be nice to establish a pattern that user defined classes could follow.  The approach of falling back to Object.prototype.toString when presented the wrong "kind" of object seems like a good general pattern for extending toString.  That is essentially alternative (b).

So, here's mky proposal:

If somebody has evidence that there are actual real world dependencies upon Date.prototype.toString() producing ToDateString(NaN) then we should go with the NaN version of (c).  Otherwise we should apply (b) to Date.prototype.toString. In either case, we should make all the other built-in toString methods that depend upon a specific kind of object also follow (b).

How about we test (b) for Date on Nightly?

Allen


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