Standard builtins' prototypes and toString

Allen Wirfs-Brock allen at
Thu Jun 12 12:30:53 PDT 2014

On Jun 12, 2014, at 12:14 PM, C. Scott Ananian wrote:

> 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!)

you're right.

Till, In the spec. we don't actually have a good way to identify any Date.prototype object from any Realm. We'd have to brand all Date.prototype objects in some way.  It could be done, but it isn't something I would expect anybody to every bother to do for user defined classes.  If such cross realm detection is actually important for Date why isn't it also important for the classes that a JS programmer defines. 


More information about the es-discuss mailing list