On Jul 9, 2012, at 12:48 PM, Norbert Lindenberg wrote:
> The ECMAScript Internationalization API Specification re-specifies several
> locale sensitive functions of the ECMAScript Language Specification by adding
> two arguments, locales and options:
> - String.prototype.localeCompare
> - Number.prototype.toLocaleString
> - Date.prototype.toLocaleString
> - Date.prototype.toLocaleDateString
> - Date.prototype.toLocaleTimeString
>
> Neither of the two specifications directly specify the length properties of
> these functions, so the introduction of ES5.1 clause 15 applies: "this value
> is equal to the largest number of named arguments shown in the subclause
> headings for the function description, including optional parameters."
>
> Using this rule, the values of the length properties would increase by two
> for these functions due to the re-specification. However, we could also apply
> the rule that Allen proposed a while ago [1], i.e., not count the new
> arguments because they're optional. Either way, I think the spec needs to
> address this.
Where we ended up that thread and what is currently coded in the ES6 draft is
(13.1) :
NOTE The ExpectedArgumentCount of a FormalParameterList is the number of
FormalParameters to the left of either the rest parameter or the first
FormalParameter with an Initialiser. A FormalParameter without an initializer
are allowed after the first parameter with an initializer but such parameters
are considered to be optional with undefined as their default value.
> From an application point of view, I think increasing the length value would
> be useful: It gives applications a direct way to detect whether the functions
> will interpret or ignore locales or options arguments.
yes, that might be nice and there is a precedent for built-in function length
values being somewhat arbitrary.
However, something that I have been thinking about recently is how to deal with
the length property when self hosting built-ins using ES. The length property
of a function is non-writable and non-configurable. That means the only control
a ES programmer has over a function's length property is the shape of the
formal parameter list. If the specified length isn't the same as what would be
generated by the most reasonable formal parameter list, the ES implementor is
going to have to pervert their formal parameters to get the right value. For
example, Array.prototype.push has a specified length property of 1. However,
an implementation like this:
function push(...items) {
...
}
would have a length property of 0, according to the ES6 rules. To get the
correct length value of 1, a self-hosting implementation would have to be
written something like:
function push(item1) {
if (arguments.length == 0) //fall back to the arguments object to
determine actual number of arguments
...
}
For all new built-in functions, life is going to be easier if they follow the
same rules as programmer defined ES6 functions. If we thought we could get
away with it (we probably can't) I'd consider respecifying the length of the
pre-ES6 built-ins to also follow those same rules.
>
> test262 checks the length values of most of the methods (not
> Number.prototype.toLocaleString). I don't know whether in web reality anybody
> depends on the current values of the length properties of these functions.
There was a thread about this recently. Apparently some people are using
length but I wasn't convinced that their usage was either valid or necessary.
>
> The API designer in me leans towards increasing the length values, but I
> expect Allen to twist my arm the other way...
Did I succeed?
Allen
>
> Comments?
>
> Thanks,
> Norbert
>
>
> [1] https://mail.mozilla.org/pipermail/es-discuss/2011-August/016361.html
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
