Standard builtins' prototypes and toString

[Till Schneidereit]

On Thu, Jun 12, 2014 at 9:30 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>
wrote:

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

Oh, sorry, I missed that.


>
> 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.
>


Fair. (Ignoring the fact that all actual implementations probably do have a
way to do this.) What about only special-casing Date.prototype from the
current Realm, then? We have %DatePrototype% for that, and it probably
covers the vast majority of the compatibility concerns.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140612/87cde18e/attachment-0001.html>