W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2013

RE: IDL: number types

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Wed, 20 Mar 2013 18:54:36 +0000
To: Allen Wirfs-Brock <allen@wirfs-brock.com>, Marcos Caceres <w3c@marcosc.com>
CC: Boris Zbarsky <bzbarsky@mit.edu>, Yehuda Katz <wycats@gmail.com>, "Anne van Kesteren" <annevk@annevk.nl>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B3853C4CEE5@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com>
> 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?

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.

> ...
Received on Wednesday, 20 March 2013 18:55:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:08 UTC