Standard builtins' prototypes and toString

[Allen Wirfs-Brock]

On Jun 12, 2014, at 8:57 AM, Erik Arvidsson wrote:

> On Thu Jun 12 2014 at 11:28:12 AM, C. Scott Ananian <ecmascript at cscott.net> wrote:
> It would be slightly more "JavaScripty" to have
> Date.prototype.[[DateValue]] exist, and be set to the epoch or some
> such.
> 
> +1
> 
> 1. Let date be the this value.
> 2. If Type(date) is not Object then, throw a TypeError exception.
> 3. If date does not have a [[DateValue]] internal slot, then let tv be NaN
> 4. Else let tv be this time value.
> 5. Return ToDateString(tv).
> 
> Allen, what is the benefit to do `super.toString()` instead?

This is really getting into how much and where we want to break legacy compatibility.

ES5 actually under specifies Data.prototype.toString.  It doesn't say what then the this value is not a Date instance.  Actually it says that the result is implementation dependent.

But, let's assume that it was in fact specified more like the current ES6 spec which your above proposed change is derived from.  The same reasoning can be applicable to the Number, String, etc. which happen to be more precisely specified in ES5. 

In that case, in ES5 (where Date.prototype is a Date instance)
   Date.prototyjpe.toString()
should produce ToDateString(NaN), and
   Date.prototype.toString.call({ });
should throw because 'date' does not have a [[DateValue]] internal slot.

Your proposed change would return ToDateString(NaN) for both cases.  So that preserves the ES5 level result when applied to Date.prototype but changes the result for any other non-Date object. 

With my proposed solution they would both produce  "[object Object]" for both cases. So it changes the result of both cases, relative to ES5. 

So both solutions change the result produce for non-Date objects. I also change the results for Date.prototype while your solution preserves it.  Which breaking change are we willing to to risk?  In making the change to non-instance prototypes we placed a bet that nobody depended upon those prototypes being instances of their constructor.  That presumably means that we were also betting that nobody is dependent upon the result you get when applying toString to those prototypes.  From that perspective, the current spec. language is a good match to our bet.  It changes what happens for toString applied to the prototype, but it preserves other Date toString behavior including throwing when Date.prototype.toString is applied to a non-Date object.  

So, I think the current spec. best matches our consensus about changing these prototypes to non-consructor instances.  I think my proposed alternative toString fall back pattern is more useful, but is a bigger breaking change. Are we willing to up the bet, or should we let it ride as is?

Allen

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