On Jun 12, 2014, at 8:57 AM, Erik Arvidsson wrote:
> On Thu Jun 12 2014 at 11:28:12 AM, C. Scott Ananian <ecmascr...@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
