length property value for functions with parameter enhancements

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Aug 29 11:29:43 PDT 2011

On Aug 29, 2011, at 2:32 AM, Andreas Rossberg wrote:

> 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.

those cases probably fall under step 16 of but we'll have to be more explicit about that.

>>>>     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.

Which is the source of the potential confusion because all of the "optional" parameters get populated with values before the rest argument gets any values.  

>> 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.

Given, that I have yet to think of a reasonable use case for function length properties, all of these rationalizations a pretty conceptual.

However, () seems like a clear statement that no arguments are required or expected while (a=0) says that an argument does have some meaning.  This seems like a worthwhile distinction to make even though 1 may not be the "typical" number of arguments.


More information about the es-discuss mailing list