- From: Marcos Caceres <w3c@marcosc.com>
- Date: Wed, 26 Jun 2013 11:04:45 +0100
- To: François REMY <francois.remy.dev@outlook.com>
- Cc: public-nextweb@w3.org
On Wednesday, June 26, 2013 at 10:27 AM, François REMY wrote: > > If possible, it would be great if you could help implement the few > > outstanding types… we are like sooo close to being done there! > > > > https://github.com/extensibleweb/webidl.js/issues > > > > … specially, if you could finish Dictionary, it would be absolutely > > awesome. The bug for dictionary has the skeleton I've laid down for it, > > but haven't yet finished. > > > > Yes, I'll make use of the fact I've to review every file to implement the > stuff still found lacking. I'll probably start with this. > > > > In any case, please file bugs describing what you plan to work on so we > > can track the work. > > > Okay, I'll try to do this, also. I don't know if it helps, but here is an example of how I'm using the different types in my own projects: https://github.com/marcoscaceres/AlarmAPI/blob/master/lib/interfaces/AlarmManager.js For example, For: AlarmManager.prototype.set = function(alarmTime, respectTZ) { var idlDate = new IDLDate(alarmTime) ... } Constructing an IDLDate with an invalid date will automatically throw, etc. Getting will always get me a "fresh" date object, and so on, in according to WebIDL. This kind of thing makes using WebIDL.js in the manner above a project a no-brainer for me. I wanted to make sure the project can continue to be used in this way, as I think it's the most logical way to use this code. The code generation part of the project is also nice, but I don't know yet how well that will scale to implementing complex interfaces in some sane manner… I guess we will need to work that out over the next few weeks/months. -- Marcos Caceres
Received on Wednesday, 26 June 2013 10:05:19 UTC