Re: Feature-detectable API extensions?

On Aug 27, 2013, at 10:03 PM, Boris Zbarsky wrote:

> On 8/28/13 12:24 AM, Allen Wirfs-Brock wrote:
>> I think that the appropriate translation of WebIDL to ES6 is that WebIDL "optional" always turns into an ES6 parameter with a default value initializer.
> 
> Why is that?  I'd like to understand the reasoning...

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.  What is typical when everything is optional?  Prior to  ES6 the length of ES code function was simply the number of formal parameters as there was no why to identify which arguments were typically not passed.  

ES6 adds the concept of parameters with default value initializers.  EG,
     function f(a, b=5) { ... }

This initializer is a way of saying: if a second argument is not passed to the call (or if undefined is passed) initialize the formal parameter 'b' to the value 5.  This is a way for the programmer to explicitly say that they don't expect callers to always pass two arguments.  In other words, the second argument is not just optional according to the ES semantics, it is also logically optional by design for this specific function.  

We still can't know whether the intent is for such argument to be typically passed or typically not passed but we assume that all parameters with default value initializers are typically not passed (to assume the opposite would just put us back to where we were with ES5).  Hence the 'length'' of a function that declares parameters with default value initializers is the number of formal parameters to the left of the first parameter with an initializer.

ES has no concept that exactly matches the WebIDL "optional" keyword.  But pragmatically the way that an ES6 programmer indicates that they consider a parameter to be optional is to supply a default value initializer for that parameter.  Hence the closest translation of WebIDL "optional" to ES6 is as a parameter with a default value initializer.

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

> 
>> If the WebIDL source includes an explicit default value then that value should be used as the ES6 default value.  If the WebIDL does not have an explicit default value then the implicit WebIDL default should be used as the ES6 default value.
> 
> There is no implicit WebIDL default value.  If there is no default value, then the argumen is "not passed" just like it would be undefined in a JS function.

In which case the default value is undefined.  ES formal parameters always get a value (possibly the value undefined) when their function is invoked. So it is quite appropriate to say that  the ES formal parameter equivalence to WebIDL "optional typename foo" is "foo=undefined".

> 
>> If you do this, then the WebIDL length based upon "optional" should match the ES8 length based upon default value initializers.
> 
> I agree, but should that be the goal?  Or would a better definition of "length" make sense for WebIDL (e.g. counting optional args without default values in the length)?

WebIDL shouldn't be looking for a "better" definition of 'length'.  ES is the programming language that web developers use and it already defines the meaning of the 'length' property of functions.  "Better" just means inconsistency.  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? 

If you want to change the ES meaning of the function 'length" property, TC39 is the place to do it.  Changing it only for WebIDL just makes things worse.

Allen

Received on Wednesday, 28 August 2013 15:49:38 UTC