- 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