Re: IDL: number types

On 3/20/13 3:44 PM, Allen Wirfs-Brock wrote:
> 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

I'd like to understand why.

The main constraints WebIDL imposes here are:

1)  Arguments are always coerced left to right.
2)  Coercions happen to whatever type you declare in WebIDL.

As you noted in your previous mail, the big problem with #2 is that it's 
not a great fit for coercing to multiple different types.

> An implementation might rewrite this into whatever language it desired,

So the thing is ... it's somewhat important to implementors to make this 
rewriting process as automatic as possible, because otherwise it becomes 
time-consuming and error-prone.

> 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

Yes, but if there is only one overload, then 
http://dev.w3.org/2006/webapi/WebIDL/#dfn-overload-resolution-algorithm 
step 8 sets d to -1, step 9 is skipped, step 11 sets i to 0, step 12 is 
skipped, step 13 is skipped, and then step 14 does:

  While i < argcount:
     Let V be argi.
     Let type be the type at index i in the type list of the single
       entry in S.
     Append to values the result of converting V to IDL type type.
     Set i to i + 1.

which is just left-to-right conversion as defined in the relevant 
section of http://dev.w3.org/2006/webapi/WebIDL/#es-type-mapping

So the fact that the overload resolution algorithm is invoked for 
[[Call]] in all cases is just a specification device.  For 
non-overloaded cases the only thing it does is step 14.

-Boris

Received on Wednesday, 20 March 2013 21:05:13 UTC