LiveScript
LiveScript copied to clipboard
Force creation of a function in a loop? (unwanted optimiziation)
Hi there, I was assembling constructor functions in a map with similar code:
# create constructors map
map = new !->
for a of type
# create constructor
@[a] = b = !->
@prop1 = false
@prop2 = false
# set its prototype (methods)
b.prototype = type[a]
the output:
map = new function(){
var a, b;
for (a in type) {
this[a] = b = fn$;
b.prototype = type[a];
}
function fn$(){
this.prop1 = false;
this.prop2 = false;
}
};
Is there a way to force creation (not definition) logic?
Huh. That looks like a bug to me, or at the very least a completely undocumented gotcha.
I can think of two workarounds, at least: change for a to for let a, or change b = !-> to b = do -> !->. Both add some overhead at run time, which is unfortunate, but it might be mostly optimized out by a JS engine.
ye, okay, i've created some factory function outside of the loop for now.. the construction overhead doesn't matter much in my case (it's a singleton object), it just doesn't look "good enough".
well, i've got some answer from the JIT-man:
"Different constructor functions will have different hidden classes"
So my intent to make some set of "look-alike" constructors with the same hidden class won't work with this pattern. Maybe, it's not a bug, i see no reason to write such code constructs now..
Looks like very same issue: https://stackoverflow.com/a/41587540/1952991
@ceremcem yes yes, it's the same.. almost.
Any update on this issue?
Nobody's working on LiveScript in secret. What you see is what you get.
Would you accept a patch that entirely removes that optimization?
Short answer, I don't know if that's a good idea. It's been a few years since I've dug into LiveScript. If you've done the research and can make a logical case that the optimization doesn't help, I'd look at it. Given LiveScript's status as a legacy language I don't want to remove anything that some project might be relying on.