W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2012

Re: [WebIDL][ES6] Include optional arguments in "length"

From: David Bruant <bruant.d@gmail.com>
Date: Wed, 17 Oct 2012 10:45:54 +0200
Message-ID: <CAHbscB1mdW6hh7LSBGBY+ck77vGmR98_yPggtP31PGYao6exGA@mail.gmail.com>
To: Simon Pieters <simonp@opera.com>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:07 UTC