Little technical question: It seems like every boolean is generated as an object containing a val attribute which is the actual boolean. Why? Wouldn't it be faster for the JS engine if it was directly a boolean?
That's a good question :)
The reason is that we need when generating code to sometimes refer to the same boolean from another variable. I.e: we need a reference to the boolean. This is possible to do in C++ (bool &myBoolean = anotherBoolean; Then if I do myBoolean = true, then anotherBoolean is modified).
Unfortunately in JavaScript, the primitives types (numbers, booleans, strings) are always assigned by value, meaning that they are copied (var myBoolean = anotherBoolean; if then do myBoolean = true, then anotherBoolean is NOT changed).
Encapsulating the boolean in an object allow to pass around this object, like a reference.
Note that there might be a way to rework code generation to avoid entirely the need for "references". I think it was useful when generating C++ code, and JavaScript code generation was copied from this implementation. But the cases where a reference is really needed might now have disappeared or be limited to a few situations where we could do using another solution (I remember it was at least useful with subinstructions like "or", so that when a sub condition is set to true, then it's actually the boolean of the "or" instructions that is set to true).
Most helpful comment
That's a good question :)
The reason is that we need when generating code to sometimes refer to the same boolean from another variable. I.e: we need a reference to the boolean. This is possible to do in C++ (
bool &myBoolean = anotherBoolean;Then if I domyBoolean = true, thenanotherBooleanis modified).Unfortunately in JavaScript, the primitives types (numbers, booleans, strings) are always assigned by value, meaning that they are copied (
var myBoolean = anotherBoolean;if then domyBoolean = true, thenanotherBooleanis NOT changed).Encapsulating the boolean in an object allow to pass around this object, like a reference.
Note that there might be a way to rework code generation to avoid entirely the need for "references". I think it was useful when generating C++ code, and JavaScript code generation was copied from this implementation. But the cases where a reference is really needed might now have disappeared or be limited to a few situations where we could do using another solution (I remember it was at least useful with subinstructions like "or", so that when a sub condition is set to true, then it's actually the boolean of the "or" instructions that is set to true).