Re: Some WebIDL.js progress

On Wednesday, June 26, 2013 at 11:49 AM, François REMY wrote:

> > 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.


I think it's quite ok for any type, to be honest (even for silly ones, like Boolean). It makes it clear in the code what is going on.    
  
> 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).


I'm personally not too concerned about performance - the Web APIs that I work on (currently) create very few objects (no more than would be common in a real implementation, I assume). That's not to say that other APIs might start to see performance issues - I just personally haven't seen this, is all. These prototypes are supposed to show exactly how an API responds to input.  

As you detail below, with Date, you kinda need the boxed model, because WebIDL always returns a new Date object on get. It's little things like that which can be overlooked, which is why I think it's better to used the boxed approach if you want to be "safe" - even with the silly types. However, if a dev knows what they are doing, then they can just ignore using them altogether.  
  
> 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.  

I am totally sympathetic to your concerns - and think the above could work. It's great to explore alternatives that are more performant and maybe keep the boxed model for more expository cases (like the ones I'm working on, where what matters most is spec prose to code conversion for the sake of spec verification above all else).

Received on Wednesday, 26 June 2013 13:32:33 UTC