Re: Feature-detectable API extensions?

On 8/28/13 11:49 AM, Allen Wirfs-Brock wrote:
> Technically, all arguments to any ECMAScript function are optional.  Formal parameters, by default, get the value undefined when a corresponding argument is not passed.
>
> The 'length'  property of an ES function is supposed to report the "typical" (ES5 15.3.5.1) number of arguments passed to the function.

I see, thank you.

So in the WebIDL case that leaves us with an interesting situation.  If 
a new argument is being added but being made optional simply to preserve 
backwards compat, it might well be that the new "typical" number of 
arguments should in fact include the new argument....

Would it make sense for WebIDL to default to not including optional 
arguments in .length but allow explicit length annotations if 
specifications want to use them, to allow using .length usefully for 
feature-detection?

> Another alternative would be to simply eliminate "optional" from WebIDL and to just directly follow the ES6 conventions.

True.  The question is what the actual semantics would be for DOM 
methods then and whether that's backwards-compatible enough... but that 
would indeed make it clearer in WebIDL which cases are just "foo" (which 
can be omitted but affects .length) and which are "foo = undefined" 
(which can be omitted and does not affect .length).  The question is 
whether we can have that distinction, which is currently avaiable in ES, 
in WebIDL as well, and if so how.

> WebIDL shouldn't be looking for a "better" definition of 'length'.

In WebIDL we can have metainformation not available to scripted 
functions about what the "typical" number of arguments for a function 
is.  Should we?

> "Better" just means inconsistency

There is already inconsistency in the sense that the mapping from WebIDL 
to concepts like "arguments with initializers" is pretty arbitrary as 
this thread shows.

>  For any particular function, how is a Web developer supposed to know if they are look at a WebIDL better length property or a regular ES length property?

Let's assume they knew.  What would they do with that information?

As far as I can see, the primary use of .length is to do detection of 
which version of a function you're dealing with if the API recently 
changed.  Are there other use cases?

> If you want to change the ES meaning of the function 'length" property, TC39 is the place to do it.

I don't think I want to change anything for ES functions here, since as 
you pointed out there is simply not much to go on for deciding on a 
"length" for them.

>  Changing it only for WebIDL just makes things worse.

I'm not proposing _changing_ anything for WebIDL.  I'm trying to figure 
out what the right way is to map WebIDL to the ES semantics here.  Even 
if we were using ES directly that problem would still be here, because 
these two ES function declarations:

   function foo(arg1, arg2) {}
   function foo(arg1, arg2 = undefined) {}

have identical behavior _except_ for .length, as far as I can tell, and 
one needs to make a conscious choice as to which one to use.

-Boris

Received on Wednesday, 28 August 2013 16:21:09 UTC