FYI for those following by email: At the TC 39 meeting last week, we decided to
apply ES6 rules to the length properties of all functions in the ECMAScript
Internationalization API. This means:
Intl.Collator.length: 0
Intl.Collator.supportedLocalesOf.length: 1
length of function returned by Intl.Collator.prototype.compare: 2
Intl.NumberFormat.length: 0
Intl.NumberFormat.supportedLocalesOf.length: 1
length of function returned by Intl.NumberFormat.prototype.format: 1
Intl.DateTimeFormat.length: 0
Intl.DateTimeFormat.supportedLocalesOf.length: 1
length of function returned by Intl.DateTimeFormat.prototype.format: 0
String.prototype.localeCompare.length: 1
Number.prototype.toLocaleString.length: 0
Date.prototype.toLocaleString.length: 0
Date.prototype.toLocaleDateString.length: 0
Date.prototype.toLocaleTimeString.length: 0
Norbert
On Jul 9, 2012, at 16:57 , Allen Wirfs-Brock wrote:
>
> 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
