Array.prototype.toLocaleString issue.

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Mar 11 11:02:41 PST 2011


Thanks,

I've created https://bugs.ecmascript.org/show_bug.cgi?id=62 to track this issue.


Both of these issues are essentially carry overs from the ES3 spec.

It may be somewhat debatable whether the second issue is a problem and there is a difference of behavior depending upon whether the getter function and/or the toLocaleFunction are strict mode or not.  Non-strict functions convert primitive this values to objects using ToObject.  That means that if the getter and toLocaleFunctions were non-strict they would still receive non === this values even if the original primitive element value was passed to both of them.  Only if they were both strict functions would they see the same value for the original element value. As currently written, a ToObject conversion is explicitly performed prior to either call and the same resulting object is passed to both functions as their this value.  Hence it is forcing a common this value in all cases including the strict mode case.

Which is more important, common observable behavior that spans both strict and non-functions in this situation, or avoiding creating unnecessary primitive wrapper objects passed to strict mode functions. It isn't clear to me that one alternative is significantly better than the other in this case.  It is probably more important that all similar situations are handed in the same manner throughout the specification.  I'll do some further digging into the spec. to see whether or not the spec. is currently self-consistent in this regard.

Also, which browser throw a TypeError?  FF4, IE8, and Safari 5 all seem to do the unspecified ToString.

Allen


On Mar 11, 2011, at 8:56 AM, Lasse Reichstein wrote:

> 
> Hi all
> I was just looking at the specification of Array.prototype.toLocaleString in tc39-2010-062-rev5p.pdf.
> 
> It accesses each element in the input array (or array-like object), and for each:
> - converts the value to an object (if not null or undefined).
> - gets its toLocaleString property (if any)
> - if that's not a callable object, throw a TypeError.
> - call the toLocaleString function with the object as this.
> - concatenate the result with the accumulator string.
> 
> The immediate problem is that if toLocaleString is a function that doesn't return a string, the concatenation
> isn't well defined (concatenating isn't formally defined in the spec, but it's otherwise only used with strings).
> The algorithm should probably do ToString on the result. I think this is what all browsers do already.
> 
> 
> Secondary, it calls the toLocaleString with the *object* as this, not the original value, leaking the internal
> ToArray conversion used to get an object to read toLocaleString from. Is this deliberate.
> Since the property can be a getter, it's possible to check that it uses the same object as base for both
> getting the function and calling it, e.g.,
> 
>  var object;
>  Object.defineProperty(Number.prototype, "toLocaleString", {get: function() {
>     object = this;
>     return function() {
>       if (this != object) { throw "spec violation"; }
>       return "42";
>     };
>  }});
>  [37].toLocaleString();
> 
> I would have expected it to use the original value, from before the ToObject call, as the this value for the
> call.
> 
> 
> Regards.
> /L
> (Some browsers try doing ToString(nextElement) if toLocaleString isn't a function, other throw the TypeError,
> seems to be approx. evenly spread).
> _______________________________________________
> es5-discuss mailing list
> es5-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es5-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es5-discuss/attachments/20110311/a7c5f362/attachment.html>


More information about the es5-discuss mailing list