Re: Please assign yourself on GH

Don't know if it helps, but for now I've changed all the constructors so that when they are called as a function they just run the internal converter. This is basically the same as what ES does (e.g., like Number(" 123 ") gives 123). So:

//x is true
x = WebIDL.Boolean({})



//x is false
x = WebIDL.Boolean(0)


and so on for each type.  

This allows some flexibility for testing:

//TypeError
x = WebIDL.UnsignedShort(" 222222 ", "EnforceRange")


//65535
x = WebIDL.UnsignedShort(" 222222 ", "Clamp")


and so on… again, this hopefully gives flexibility in both using the boxed model or working unboxed.  

Hopefully that gives us a happy middle ground?:  

1. can work unboxed
2. can work boxed
3. can easily access the converter function
(through WebIDL.Whatever.prototype.converter and x.converter)

WDYT?  
--  
Marcos Caceres


On Wednesday, January 9, 2013 at 8:27 PM, François REMY wrote:

> > The problem above is that you are converting twice:
> > What you actually want is just:
> >  
> > function not(a){
> > //to WebIDL...
> > var x = WebIDL.Boolean(a);
> >  
> > //back to JavaScript
> > return !x.value
> > }
> >  
> >  
> > Which works as expected. That's how I envisioned conversion would be done for all types.
>  
> But, then, your function doesn't return a WebIDL Boolean, but an unboxed boolean... What's the point of boxing the boolean inside the function then?
>  
>  
> > > I do think that DOMTypes should define a typechecker/converter and not necessarily rely on a true box class.
> >  
> > I'm not groking what "a true box class" is.
>  
> Did you already work on a compiler? If not, that may be the reason.
>  
> A box class is something like the String class of JavaScript. By default, a string is a value in JavaScript. However, if you "box" the String, you create an object structure around it. You can "unbox" the String if needed, and in fact this is what every native API will do when you call them with a String object.
>  
> A box is very costly because it requires unboxing and unboxing requires typechecking. Also, an object is very costly in ECMAScript from a memory point of view because it's a dictionary. However, most of the times, compilers find a way to avoid boxing.
>  
> We really don't want to add boxing in our code as well because the compiler will not be able to optimize our boxing code for us.
>  
>  
> > So I've been thinking of the same thing, but slightly differently (I personally have reservations about the de-coupling to a TypeChecker function). Each type already defines its converter, so we could expose it (my preferred option):
> >  
> > //returns the converter function - which can be used in code generation, etc.
> > WebIDL.WhateverType.converter;
>  
>  
>  
> This is a good idea. I would use a name more difficult to guess like __converter__ and set the property as non-enumerable, but I agree on the principle. Initially, I planned to comment about the efficiency of a fastpath for the most common conversions, but in fact it doesn't matter how fast the runtime conversion will be since the compiler will still optimize the usual operations via a code emitter instead of a runtime check.
>  
>  
> > I don't have a strong opinion about the above at this point, to be honest. But my feeling is that you are getting ahead of the game (this is not a bad thing and not a criticism! and I think it's really great that you are thinking about potential pitfalls down the line.).
>  
> I'm not really thinking too far, I just make sure we don't write code for nothing. The conversions should not be defined as a library feature but rather as a code emitter. If you define conversion features as a part of your library, you transform your library into a requirement for your compiled code. Since your typing code requires RequireJS, your compiled code will do so, too. This is a non-starter. Actually, I do think you should consider our task more like an HTML templating engine where you generate JavaScript code instead of HTML than like a javascript program that create runtime objects.
>  
>  
>  
> > Remember the golden rule: 99% of this stuff will probably re-rewritten and nothing is set in stone :) Lets prototype, go crazy with ideas, and rapidly make something awesome by learning from mistakes/challenges. Yeah?
>  
> This is not because the code will have to be rewritten that you should not try to make the best code possible ^_^ But yeah, I agree with you in general ;-)

Received on Thursday, 10 January 2013 20:15:20 UTC