Standard builtins' prototypes and toString

C. Scott Ananian ecmascript at
Thu Jun 12 12:14:17 PDT 2014

On Thu, Jun 12, 2014 at 3:06 PM, Till Schneidereit
<till at> wrote:
> On Thu, Jun 12, 2014 at 8:29 PM, C. Scott Ananian <ecmascript at>
> wrote:
>> (a) `#toString` throws TypeError when given a non-instance.  Changes
>> `Date#toString()`, no change to `{})`.
>> (b) `#toString` is generic; invokes `Object#toString` when given a
>> non-instance.  Changes both `Date#toString()` and
>> `{})`.
>> (c) `#toString` is generic; uses a "zero" value when given a
>> non-instance.  No change to `Date#toString()`; changes
>> `{})`.
>> (d) `#toString` returns a "zero" value when given a prototype, throws
>> TypeError otherwise. No change to `Date#toString()` or
>> `{})`.
> There is (e) `#toString` returns "[object Object]" when invoked on the (an)
> original Date.prototype (regardless of the Realm it came from). Otherwise,
> it throws when invoked on a non-instance.
> This is what Allen and me proposed.

Allen said:
> 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.

...which is option (b).  (Allen, correct me if I'm reading that wrong!)

More information about the es-discuss mailing list