Standard builtins' prototypes and toString

[Mark S. Miller]

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 <ecmascript at cscott.net>
wrote:

> On Thu, Jun 12, 2014 at 12:59 PM, Allen Wirfs-Brock
> <allen at wirfs-brock.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140612/897a6b5b/attachment.html>