- 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