length property value for functions with parameter enhancements

Andreas Rossberg rossberg at google.com
Mon Aug 29 02:32:28 PDT 2011


On 29 August 2011 01:36, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> On Aug 27, 2011, at 6:12 AM, Andreas Rossberg wrote:
>> True, and actually, there are more issues with length & function
>> proxies. I don't have my notes with me right now, but for example, it
>> is not clear at all what length Function.prototype.bind should set
>> when called on a function proxy. 0? 1? Should it try to get the length
>> property from the proxy and subtract N? What if length is not defined
>> on the proxy, or not a (natural) number?
>
> The ES5.1 spec.  defines how how bind determines the length for the function it creates based upon the length property of the target function.  I would expect the same rules would apply when the target is a function proxy.

Ah, right, I was looking at the 5.0 spec 8-}. However, that is still
not good enough for function proxies, because you have no guarantee
that they define length at all, or make it a natural number. So we at
least have to include additional error cases, and a solution for them.

>>>     function bam(a,b,c=0,...d) {} //bam.length==2   BTW, is this legal?
>>
>> Makes sense. (And yes, I don't see why the latter shouldn't be legal.)
> Because the is a  potential for misinterpreting the user intent on such a call.  For
>    bam('a','b',1,2,3)
> we surely have to interpret the argument/parameter mapping as:
>     a='a',b='b',c=1,d=[2,3]
> but it is easy to imagine a programmer intending
>     a='a',b='b',c=0,d=[1,2,3]
> Making it illegal to have a formal parameter list that has both optional and result parameters might result the likelihood of that confusion,

Hm, that doesn't sound like a very JavaScripty argument :). If you buy
into optional arguments at all, then I can certainly envision valid
use cases for combining them with rest arguments.

>>> If there are no non-optional or non-rest formal parameters the length is 1.
>>>     function bar1(a=0) {} //bar1.length=1
>>>     function baz1(a=0,b=1,c=2) {} //baz1.length=1
>>>     function bam1(...a) {} //bam1.length==1
>>
>> I'm not so sure about this, it seems incoherent. Why not 0, especially
>> for the first two? You mentioned builtins like Array above, but I
>> would rather count them as the exception to the rule (especially given
>> that the builtins don't seem entirely consistent wrt length anyway).
>
> In my proposal, I am decided to make a clear distinction between truly empty  formal parameter lists and  those with only various forms of optional formal parameters by only giving a 0 length to the empty formals case.  That's a debatable decision but it seems desirable to distinguish the two cases and the built-ins is the only precedent that we have to follow.

I guess I don't see what is special about empty argument lists. Why
would you want to make a clearer distinction between the argument
lists () and (a=0), than between (x) and (x, a=0)? You seem to be
introducing a discontinuity.

>> FWIW, one could also argue for setting length to +infinity for
>> functions with only rest parameters. :)
>
> But there is no precedent for that and surely infinity is not the "typical" number of arguments.

Yeah, I wasn't being serious.

> I'm not sure if there is any real use case for the length property of ECMAScript functions.  Does anybody know of one? Regardless, I do think we can get rid of it.

"Do not", I suppose? (Unfortunately, as I was wondering the same.)

/Andreas


More information about the es-discuss mailing list