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

Marcos - Happy to vote - but want to make an observation/point before we
do:

RequireJS forces an async nature to the entire lib. This causes a blip in
it's usability by prollyfills using it in a compiled state and even by us
when we work with it in a decomposed state.

I think there is a 1.5 choice:

I want to create a build system that composes the web-idl.js as a whole
for testing/running while allowing me to code in separated source files.

(I would point to the work that the Ember.js team have been doing in this
aspect as guidance.They've done really smart things with mini-spade,
sourceMap etc.)



On 1/9/13 1:59 PM, "Marcos Caceres" <w3c@marcosc.com> wrote:

>
>
>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:10:59 UTC