Open determin1st opened 5 years ago
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.
Hi there, I was assembling constructor functions in a map with similar code:
the output:
Is there a way to force creation (not definition) logic?