While we're on the topic, shall we discuss `valueOf()`? Should it get the same treatment? --scott On Jun 19, 2014 1:28 PM, "Allen Wirfs-Brock" <[email protected]> wrote:
> > On Jun 19, 2014, at 3:18 AM, Till Schneidereit wrote: > > On Thu, Jun 19, 2014 at 1:39 AM, Allen Wirfs-Brock <[email protected]> > wrote: > >> >> On Jun 18, 2014, at 4:12 PM, Brendan Eich wrote: >> >> > Allen Wirfs-Brock wrote: >> >> The spec. current says throw for this Symbol.prototype case. The >> (reasonable) opposing view is that toString should never throw. Other than >> the protoype-is-not-an-instance it all about unlikely edge cases where >> toString methods are applied to the wrong kind of object. >> > >> > js> Object.create(null).toString() >> > typein:1:0 TypeError: Object.create(...).toString is not a function >> > >> > It happens. Better to catch that error (Symbol.prototype flowing into >> an implicit conversion) early? >> >> which is pretty much the approach the ES6 spec. has taken WRT toString up >> to now. Tension between catching invalid iplicit toString conversions and >> reliable toString for debugging. >> > > I'd posit that there are three different cases for toString: > 1) (explictly or implicitly) calling foo.toString, where `foo` is any of > the objects that, by default, exist in a JS global without any user code > having run > 2) (explicitly or implicitly) calling foo.toString, where `foo` is some > content script-generated object > 3) explicitly calling bar.toString.call(foo), where `foo` and `bar` are > arbitrary objects > > The current (ES5) state of things is that 1) can never throw, while both > 2) and 3) might. The current ES6 draft would move 1) over into the latter > camp. I think *that* is the crucial thing to prevent. It's just wrong for > the language to essentially say "here's a bunch of objects. They have > methods. But don't call all of them. Finding out which ones aren't allowed > to be called is left as an excercise to the reader." > > Theoretically, Scott's #d still hold the most appeal to me. However, I > don't think it works in a multi-Realm world, hence "theoretically". Given > that, it's #b or #c, where, again, I don't much care which one it'll be. > > > Or even in a single Realm world, it isn't clear how: > (class extends Date {}).prototype.toString() > would recognize that is is dealing with a prototype rather than a Date > instance. > > I basically agree with you conclusion. An the conserve thing to do is to > try to minimize legacy compat. To me, that says that for Date, Number, > Boolean, String, RegExp we should do (c). For new kinds of objects that > don't exist in ES5 and which have internal state dependent toStrings we > should do (b). > > I'll update the spec. accordingly. > > Note that for the (c) cases this introduces a different breaking change: > ES5 specifies that String.prototype.toString.call({}) throws a TypeError > but the (c) based change will return the empty string for that case. > Hopefully, that is a change the web can live with. > > Allen > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
