Call for vote on structure - Re: Please assign yourself on GH

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?
The point was that it went through the conversion. That is all.  
  
> > > 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.

No, I have not had that pleasure :)    
> 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.

gotcha.   
>  
> 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.
Yes, I agree.  

> 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.
Absolutely. Boxing right now is just for convenience. I was not envisioning that any boxing would happen upon code generation later in the project. However, conversion MUST happen.  
    
> > 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.
Ok, cool :) I think we are totally on the same page.   
> > 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.

Ok, take a step back for a minute. Right now, the only cruft we are adding is this:

define(function(require) {
var IDLType = require("types/IDLType"),
WebIDL = require("interfaces/WebIDL");


WebIDL.WhatEver = function(value) { this.value = value }

function toWhatever(V) {  
//do whatever WebIDL says in section 4 for Whatever
}
WebIDL.Whatever.prototype = new IDLType('Whatever', toWhatever);
});

Now, we could do away with those 10-20 lines of code and just write all the toWhatever() functions (and throw them all into separate files). That's fine and mostly works. There are some special types, like Date, that require a bit more cruft as part of the getting/setting, but not too much.  

The only argument/plea I make is that using the above structure helps keep our code organized, and makes it easy to load up things we want to play with easily:  

require(['types/Boolean', 'types/Double', 'types/Octet', 'types/Date', 'types/DOMString']);

So, yes, we could initially simplify things even further by putting all the toWhatever converters either in the global scope or on some predefined object (e.g., window.webIDL).  

I'm ok to go either way - but I'm happy to just keep going with AMD though there is little advantage apart from the encapsulation.  

How do other people feel about this? Like I said: coding WebIDL algorithms are all the matter irrespective of wrapper.  
  
> > 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 ;-)  

Again the best code is in the converters (the rest is sugar/cruft). Lets take a vote:  

1. I want to continue with AMD and boxed types (i.e., continue with what we got)?
2. I want to just have have functions (or something similar) with no AMD and no boxing, etc.?
3. I don't care.  

My vote is for 1, though I would be just as happy with 2.

Received on Wednesday, 9 January 2013 21:00:08 UTC