FWIWI, toString, as well as toLocaleString in the Object.prototype, has
been used as a hack to bring non-enumerable properties in Internet Explorer
8 and lower.

I am not sure what will be, but if anything to not break the web, should
consider this fact, even if not concerned as I am about IE8 usage in 2014.

Best Regards


On Tue, Dec 10, 2013 at 9:55 PM, Norbert Lindenberg <
ecmascript at lindenbergsoftware.com> wrote:

> All ECMAScript objects have a toLocaleString method, originally defined in
> Object.prototype and overridden in Array, Number, and Date. The parameter
> list of this method has changed over time:
>
> - In ES3 and ES5, the methods don't take parameters, but there's a note
> "The first parameter to this function is likely to be used in a future
> version of this standard; it is recommended that implementations do not use
> this parameter position for anything else."
>
> - In ECMA-402 first edition, we respecified
> Number.prototype.toLocaleString and Date.prototype.toLocaleString to take
> two parameters (locales and objects).
>
> - In the current draft of ES6, the specs for these two methods are changed
> to reserve the two parameter positions and to require that they're either
> used as specified in ECMA-402 or not used for any other purpose.
>
> That leaves the toLocaleString methods in Object and Array somewhat
> incompatible with Number and Date: Their specs still reserve the first
> parameter, but not the second. And Array.prototype.toLocaleString, which
> calls toLocaleString on all elements of an array, does not pass on any
> arguments, thus breaking localization for any Number or Date objects the
> array may contain.
>
> I can see the following ways to resolve this:
>
> - Remove the notes about the first parameter on toLocaleString in Object
> and Array, and accept that they will not be properly localized. Most
> compatible, least localization friendly.
>
> - Reserve the first two parameters on toLocaleString in Object and Array,
> and specify that they must always be ignored in Object, and always be
> passed on to the toLocaleString calls on the elements in Array. One issue
> here is that the toLocaleString methods on Number and Date throw exceptions
> if provided invalid arguments, so a call to Array.prototype.toLocaleString
> can result in an exception if a Number or Date instance is present in the
> array while completing normally otherwise.
>
> - Reserve the first two parameters on toLocaleString in Object and Array,
> allow a future version of ECMA-402 to specify how to use them, and require
> that the parameters are ignored in ES6 implementations that don't also
> implement a version of ECMA-402 specifying their use. The next version of
> ECMA-402 could then require a stricter implementation that always checks
> locales and options.localeMatcher for validity, even when called on an
> empty array or object, and passes the parameters on to an array's elements.
>
> Thoughts about the best way to proceed?
>
> Thanks,
> Norbert
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131210/7d4e5f16/attachment.html>

FWIWI, toString, as well as toLocaleString in the Object.prototype, has
been used as a hack to bring non-enumerable properties in Internet Explorer
8 and lower.

I am not sure what will be, but if anything to not break the web, should
consider this fact, even if not concerned as I am about IE8 usage in 2014.