- From: François REMY <francois.remy.dev@outlook.com>
- Date: Wed, 26 Jun 2013 10:47:10 +0200
- To: <public-nextweb@w3.org>
- Message-ID: <DUB120-DS170F29D3D3670E4C636A60A5740@phx.gbl>
Hi guys, I’m on holiday until the 7th of July, and therefore I have some time to work on WebIDL.js. Yesterday, I made some progress on the typescript code generator. https://github.com/extensibleweb/webidl.js/blob/typescript/typescript/default.htm Today, I would like to add the autogeneration of arguments checks for non-overloaded methods but I noticed the API had some usability issues from that point of view. I would prefer it to be defined in this way: interface WebIDL.Converters { [name: string]: WebIDL.Converter<any> } interface WebIDL.Converter<V> { // return true if “v” is a normal JS value for an instance of V canCast(v: any): bool // return true if “v” could be converted to an instance of V canConvert(v: any): bool // return “v” if it is an instance of V, or throw cast(v: any): V // convert “v” to an instance of V, or throw convert(v: any, attributes?: IDLAttribute[]): V } The usages are the following: Converter.canCast: - to check return values against return type - to select the best calling convention (overloaded methods) Converter.canConvert: - to select an appropriate calling convention if none matched exactly (overloaded methods) Converter.cast/convert: - to perform the casting/conversion Marcos, is it okay if I refactor the current files using this pattern or do you actively rely on the current structure already?
Received on Wednesday, 26 June 2013 08:47:42 UTC