RE: Please assign yourself on GH

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.

I do think that DOMTypes should define a typechecker/converter and not necessarily rely on a true box class. In other words:

     a = TypeCheck(a, WebIDL.Boolean);
     return !a;

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;
          }
     }

----------------------------------------
> Date: Wed, 9 Jan 2013 17:22:47 +0000
> From: marcos@marcosc.com
> To: francois.remy.dev@outlook.com
> CC: public-nextweb@w3.org
> Subject: Re: Please assign yourself on GH
>
> Hi François,
>
> On Wednesday, January 9, 2013 at 4:34 PM, François REMY wrote:
>
> > I'll. But I've a general comment about your code: you assume Boolean, Double and DOMString are special types, but if you want to work with them in JavaScript, this will be a pain.
>
> Sort of, yes. The important thing is the casting.
> > I think we should just use "true" and "false" for Boolean, a normal JS string for DOMString. That means: just converters, no real type.
>
> I'd prefer to have the types for now. It's only to make sure we don't miss anything.
> > Boxing of values is generally not a good idea, if you want humans to modify the code (which we want).
>
> Can you explain a bit more what you mean here (i.e., how would people modify the code)?
>
> --
> Marcos Caceres
>
>
>
>

Received on Wednesday, 9 January 2013 17:45:17 UTC