Open jdalton opened 7 years ago
From the perspective of the importing module, live bindings are supposed to be immutable regardless of how they were declared in the exporting module, so (just to be clear) the const
in the first module doesn't matter here.
As you know, the Reify-compiled version of the variable has to be mutable so that the setter function can assign it any value(s). There's nothing we can do about that, so I'm afraid Node can't help us once the code has been compiled.
If you use the Babel plugin, the compiler should raise an exception in this case, because it considers value
to be immutable (even though it can technically still be modified by the setter function).
Perhaps the Reify compiler should throw if it finds any assignments to imported symbols? Should that be the default behavior, and/or configurable?
From the perspective of the importing module, live bindings are supposed to be immutable regardless of how they were declared in the exporting module, so (just to be clear) the const in the first module doesn't matter here.
Ah nice!
Perhaps the Reify compiler should throw if it finds any assignments to imported symbols? Should that be the default behavior, and/or configurable?
If it can't be caught at runtime then a compile time check seems right. Since it's spec compliance stuff I think on-by-default is good (making it configurable is dealers choice).
In adding a unit test for modifying a constant value I noticed a gap.
const.js
test.js
It should throw since
value
is aconst
, but currently reify doesn't track imported values, so doesn't wrap them in a setter call. It also definesvalue
with eithervar
orlet
but that prolly doesn't matter as much because if it were wrapped in a setter call an error would get thrown in theconst
module.