On Thu, Jun 12, 2014 at 9:30 PM, Allen Wirfs-Brock <[email protected]> wrote:
> > On Jun 12, 2014, at 12:14 PM, C. Scott Ananian wrote: > > > On Thu, Jun 12, 2014 at 3:06 PM, Till Schneidereit > > <[email protected]> wrote: > >> On Thu, Jun 12, 2014 at 8:29 PM, C. Scott Ananian < > [email protected]> > >> 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.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
