This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently the spec says that .length on function objects is equal to the minimum possible number of arguments. In particular, optional arguments are ignored. This is bad, because it means that if a spec originally defined f(int x) and later adds an optional argument f(int x, optional int y), there's absolutely no way to feature-test whether the extra argument is supported. Calling f() with two arguments in old browsers will silently ignore the second argument, which is not useful. If this is to match ES6, why can't we just change ES6? Is there a reason ES6 ignores optional arguments for the purposes of .length? This is a new feature, so we should be able to change it. All I was able to find on the subject is: """ The length property of a function should be updated to not include optional parameters. — Erik Arvidsson 2010/11/05 22:37 """ http://wiki.ecmascript.org/doku.php?id=harmony:parameter_default_values But he doesn't give a reason. zcorpan just mailed public-script-coord asking that this be changed in both ES6 and WebIDL: http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0039.html See also Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=793151
There has been lot of discussion regarding this and at the moment we are sticking to what is in the ES6 draft. Function .length is not very useful either way you go. To be able to do feature detection related to the arity of a function a better reflection mechanism is needed. For example, DOMTokenList.prototype.add changed from "DOMString token" to "DOMString... tokens". Would you want length to be 0, 1 or Infinity in that case? With ES6 length becomes 0 because that is the number of required parameters, the least number of parameters needed for the function to "work".
In support of Erik's comment, this is the latest relevant discussion thread: https://mail.mozilla.org/pipermail/es-discuss/2012-October/025711.html
FWIW, I would expect the minimum amount of required parameters for DOMTokenList.prototype.add to be 1, not 0.
(In reply to comment #3) > FWIW, I would expect the minimum amount of required parameters for > DOMTokenList.prototype.add to be 1, not 0. If that is the case we should update the IDL to: add(DOMString token, DOMString... tokens) There is no way to look at add(DOMString... tokens) and see that it needs at least one parameter.
I thought that would be the difference between "optional DOMString..." and "DOMString...". Hmm. I guess no arguments is okay... it's just a no-op then.
Thanks for the link, Rick! I read through it briefly, and didn't come away with any specific reasons to stick with the current spec other than "it better matches existing built-ins, and we've discussed this detail far more than its importance warrants, so please let's just stick with what we have". To be honest, though, that doesn't seem like a bad reason to me. Even leaving aside the rest parameter, .length is of dubious value anyway. Plus, three out of four browser engines just always set .length to 0 for WebIDL operations, so it's not like it's really going to be useful to anyone anyway. I still favor changing it based on the arguments I've seen so far, but if the ES people have discussed it a lot and change looks unlikely, I'm not going to try arguing. It's not very important and we all have better things to do. So I'd be okay with WONTFIX as a resolution here, and Mozilla can land the change to match the WebIDL spec. (An alternative would be for WebIDL to deviate from ES, but that seems even less desirable.)
Thanks for looking into this, everyone. Given that ES6 is staying as it is, I think WONTFIX is the right thing to do.