Re: IDL: number types

On Mar 20, 2013, at 11:54 AM, Travis Leithead wrote:

>> From: Allen Wirfs-Brock [mailto:allen@wirfs-brock.com]
>> ... 
>> So, what's a solution?  I appreciate that the ES specification technique
>> perhaps requires too high of a skill level for a broad set of spec. writers.  So,
>> my solution would be to require all new Web APIs to be specified using ES
>> code (which in some cases may wrap pseudo-code)  The ES code would do all
>> the necessary implicit or explicit argument corrosions using normal ES
>> coercion code patterns.  
> 
> So, declarations in WebIDL would all take "var" as the type, and algorithm descriptions for the APIs would be 
> required to reuse ES explicit conversions to get the var into desired form? Or is this not what you meant?

WebIDL types are fine (when used appropriately) as documentation but they are a poor fit to ES for specify the actual coercions and their sequencing   

What I literally mean is that the Web API specification (assuming there was one)  of  the ES5 Array.prototype.forEach algorithm would look very similar to the ES code given at https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Array/forEach#Compatibility  which starts out like:

Array.prototype.forEach = function forEach( callback, thisArg ) {
 
    var T, k;
 
    if ( this == null ) {
      throw new TypeError( "this is null or not defined" );
    }
 
    // 1. Let O be the result of calling ToObject passing the |this| value as the argument.
    var O = Object(this);
 
    // 2. Let lenValue be the result of calling the Get internal method of O with the argument "length".
    // 3. Let len be ToUint32(lenValue).
    var len = O.length >>> 0; // Hack to convert O.length to a UInt32
 
    // 4. If IsCallable(callback) is false, throw a TypeError exception.
    // See: http://es5.github.com/#x9.11
    if ( {}.toString.call(callback) !== "[object Function]" ) {
      throw new TypeError( callback + " is not a function" );
    }


Note the explicit null check and object coercion of the t this value, the explicit Uint conversion (using modulo) of the array length, and the check that the first argument is a function that only occurs after the length is accessed.  If accessing the length had any side-effect they are specified to observably occur before an exception would be thrown for an invalid function argument.

An implementation might rewrite this into whatever language it desired, also long as it maintained the sequencing of the observable side-effects of all intermediate steps.


> 
> It seems like these coersions are already syntactically embedded into the WebIDL types. The overload resolution algorithm only kicks in when you have parameter overloads or union types which the API is expected to pick-and-chose different behavior based on the input parameters--I think APIs that require this are relatively few and far-between.

That's not what the current WebIDL draft says http://dev.w3.org/2006/webapi/WebIDL/#call Step 2 of a [[call]] always calls the over-load resolution algorithm and it that that algorithm that does all coercions.  The WebIDL syntactic signature is essentially the pattern that drives this algorithm.  

Allen





> 
>> ...
>