- From: David Bruant <bruant.d@gmail.com>
- Date: Wed, 17 Oct 2012 10:45:54 +0200
- To: Simon Pieters <simonp@opera.com>
- Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
- Message-ID: <CAHbscB1mdW6hh7LSBGBY+ck77vGmR98_yPggtP31PGYao6exGA@mail.gmail.com>
2012/10/17 Simon Pieters <simonp@opera.com> > Hi, > > ES6 and WebIDL do not include optional arguments in the "length" property. > It would be more useful for feature testing DOM stuff if they were. Gecko > currently includes them for DOM stuff, but there's a bug > https://bugzilla.mozilla.org/**show_bug.cgi?id=793151<https://bugzilla.mozilla.org/show_bug.cgi?id=793151>about changing it to match current WebIDL. IE/Opera/WebKit seem to always > use 0 for DOM stuff. WebIDL is apparently aligned with ES6: "The length > property of a function should be updated to not include optional > parameters." http://wiki.ecmascript.org/**doku.php?id=harmony:parameter_** > default_values<http://wiki.ecmascript.org/doku.php?id=harmony:parameter_default_values> > > Always using 0 is quite useless for feature testing, but not including > optional arguments is also useless since you can't tell if the UA > implements the optional argument or not. What was the rationale for not > including optional arguments in length in ES6? Can we change both ES6 and > WebIDL to include them? I assume you meant "feature detection" instead of "feature testing". I'm not sure function.length should be used for feature detection. A number is ambiguous. For instance, what could you tell from a UA implementing window.open with length 3? Maybe a middle argument was skipped. If the problem being solved is feature detection, I would be much happier if WebIDL defined a way to define either *named* properties on the function object itself or why not symbols (previously known as "private names") if these are widespread early enough (which I doubt will happen, but I'm writing the idea for the sake of completeness). Specifically, I would be happy to read code like: if('transferable' in someIFrame.postMessage){...}else{...} // or if(someIFrame.postMessage.transferable){...}else{...} but more annoyed to have to figure out what the following means if(someDOMMethod.length === 2){...}else{...} Ideally, people would add comments... but reality is rarely ideal. I introduce this part by "If the problem being solved is...", because I'm not completely sold it's a problem worth solving at the spec level. David
Received on Wednesday, 17 October 2012 08:46:21 UTC