Re: Please assign yourself on GH

On Wednesday, January 9, 2013 at 5:44 PM, François REMY wrote:

> Simple, let's say we have the following interface:
>  
> interface A {
> Boolean not(Boolean a);
> }
>  
> if you want to implement it in JS, you'll write something like
>  
> function not(a) {
> a=!!a;
> return !a;
> }
>  
> if you goal is to do things like
>  
> function not(a) {
> a = Boolean(a); // convert-typecheck
> return Boolean(!a.value) // convert-typecheck
> }
>  
> then you get a non-working algorithm as 'a' will be an object an '!a' of an object is always false: so !!(A.not(true))===true.
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.  
  
> 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.  
  
Remember that there are _all_ DOMTypes. However, in all cases we have to covert to WebIDL types to get the expected value (even in the stupid cases, like WebIDL.Boolean, which is really just "return Boolean(x)"… same with String, unless we also do the Unicode conversion).   
> In other words:
>  
> a = TypeCheck(a, WebIDL.Boolean);
> return !a;

That could certainly work, but it achieves the same thing AFAICT.  
   
>  
> where TypeCheck would be something like
>  
> funtion TypeCheck(obj, type, orNull) {
> try {
> switch(type) {
> case WebIDL.Boolean:
> return !!obj;
> case WebIDL.Double:
> return 0+obj;
> case WebIDL.DOMString:
> return ""+obj;
> ...
> default:
> if(obj instanceof type) { return obj; }
> else { throw new TypeError("...") }
> break;
> }
> } catch(ex) {
> if(orNull) return null;
> throw ex;
> }
> }
>  

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;  

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

However, at this point in the game, we really just want to see all the conversion algorithms written *precisely* to spec.  

The WebIDL.WhatEver cruft right now is just a convenient way for us to make objects and test stuff. If we then need to throw all that wrapper stuff away, that's cool. But having the "JS <-> WebIDL" code and tests is the important thing right now. Once we have that, we can refactor this to better suit our goals.  

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?

Received on Wednesday, 9 January 2013 18:58:21 UTC