Thu Oct 23 18:46:30 PDT 2008
> scoping const
> scoping const is not so much about how we write up the spec; there is a semantic definition problem - wanted const as applicable to vars and not on properties of objects with read barriers - but then what do we do about top level consts? - its base would be a special object environment - const declaration treated as the creation of a property whose value was readonly - at the instantiation of the binding it would be set of undefined, readonly and configurable- but readonly does not create a read barrier - strict mode needs to behave differently - read barrier needs to be unconditional - objection to semantics requiring a read barrier (from a performance perspective) - actually, in ES-H we will want let and const to behave consistently - looks like the semantics are not representable cleanly as the semantics of a property - two options to address the use-before-initialize problem (a) dynamic dead zone: runtime read barrier (b) static dead zone: set of stati
c rules that prevent the read -before-initialization, and thereby removing the need for a read barrier - dynamic dead zone is practical, but static dead zone would be better - not sure if we have the time to nail down the rules in time for ES3.1 - so we have the option of either going with the dynamic dead zone, or pulling const out of ES3.1.
If the object model we're pushing for 3.1 does not support top-level const then I believe the model is broken. Trying to standardize such a model in ES3.1 seems premature, as it would risk blocking future evolution of the language.
More information about the Es-discuss