Re: Some WebIDL.js progress

> AlarmManager.prototype.set = function(alarmTime, respectTZ) {
> var idlDate = new IDLDate(alarmTime)
> ...
> }

So you're basically boxing the types all the times, right now. It's probably 
cumbersome for usual types (doubles...) but I agree this is a good approach 
for the less usual ones (like int32) since you can extend the boxes with new 
operations that are unavailable to the external JS world.

However, boxing using JS objects is really very expensive due to the GC 
overhead this can cause, so I would avoid it for the case where it's not 
necessary (string, bool, unrestricted double, and even Date).

The idea I had about Date was the was "cast on reception, cast on exit, but 
stay with native JS types in-between", so something like:

//
// I didn't check the spec, this is just a proof of concept
//

{
    canCast(v) { return (v insteanceof Date); }
    canConvert(v) { ... }
    cast(v) { if(this.canCast(v)) { return this.convert(v); } else { throw 
... } } // Date is a value-type in IDL so references shouldn't be transfered 
on casting
    convert(v) { return new Date(+v); }
    unconvert(v) { return this.cast(v); }
}

and, in usage:

var DateConverter =
    <WebIDL.Converter<Date>>(
        WebIDL.Converters["Date"]
    );

class Alarm {

    private __alarmDate: Date;
    get alarmDate(): Date {
        return DateConverter.unconvert(this.__alarmDate); // unconvert 
output arguments
    }
    set alarmDate(v: Date) {
        v = DateConveter.convert(v); // convert input arguments
        this.__alarmDate = v;
    }

    delay(numberOfSeconds: number) {
        this.__alarmDate.setTime(numberOfSeconds + (+this.__alarmDate));
    }

}

but I'm fine with keeping the boxed types as they are & which would use the 
converters internally like they do now. I would just prefer not to tie so 
much the converters and the boxed type toegether like it is now.

Received on Wednesday, 26 June 2013 10:50:25 UTC