I like this list. I prefer #c. * We have previously succeeded at making previously non-generic methods generic. I think we could get away with #c. * It is easier for a normal JS programmer to do the equivalent of #c for most of their classes. * Doesn't requiring branding the builtin prototypes unnecessarily. * Works fine across Realms.
On Thu, Jun 12, 2014 at 11:29 AM, C. Scott Ananian <[email protected]> wrote: > On Thu, Jun 12, 2014 at 12:59 PM, Allen Wirfs-Brock > <[email protected]> wrote: > > So, I think the current spec. best matches our consensus about changing > > these prototypes to non-consructor instances. I think my proposed > > alternative toString fall back pattern is more useful, but is a bigger > > breaking change. Are we willing to up the bet, or should we let it ride > as > > is? > > Just restating and naming the alternatives: > > (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({})`. > > Option (a) is what is in the current spec. > Options (b) and (c) make the `toString` method generic. > Option (d) preserves compatibility to the greatest degree possible. > --scott > > ps. I prefer (a). > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
