Standard builtins' prototypes and toString

[C. Scott Ananian]

On Thu, Jun 12, 2014 at 3:06 PM, Till Schneidereit
<till at tillschneidereit.net> wrote:
> On Thu, Jun 12, 2014 at 8:29 PM, C. Scott Ananian <ecmascript at cscott.net>
> wrote:
>> (a) `#toString` throws TypeError when given a non-instance.  Changes
>> `Date#toString()`, no change to `Date#toString.call({})`.
>>
>> (b) `#toString` is generic; invokes `Object#toString` when given a
>> non-instance.  Changes both `Date#toString()` and
>> `Date#toString.call({})`.
>>
>> (c) `#toString` is generic; uses a "zero" value when given a
>> non-instance.  No change to `Date#toString()`; changes
>> `Date#toString.call({})`.
>>
>> (d) `#toString` returns a "zero" value when given a prototype, throws
>> TypeError otherwise. No change to `Date#toString()` or
>> `Date#toString.call({})`.
>
> 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!)
  --scott