On 10/14/10 08:11, Brendan Eich wrote:
On Oct 13, 2010, at 11:56 PM, Erik Corry wrote:
The semantics for const in Harmony are likely to be silently different
in Harmony from the semantics it has in non-strict current
implementations. (In particular the current const is hoisted to the
surrounding function, whereas the one in Harmony won't, so the
shadowing will be different.)
Agreed so far. IIRC const in Opera is just a synonym for var.
Given this silent behavioural change it would be advantageous to flush
out existing uses of const before Harmony arrives and gives it a new
meaning.
Flush out means make developers find all such uses, and do what?
Forbidding const in strict mode would seem to be a way to do that.
If only I knew what "flush out" means. Users may or may not rewrite complex
const-using code just to enable strict mode.
The problem is even more acute for let-based code -- Mozilla JS (Firefox FE and add-on
code) uses let heavily. It's a sunk cost, arguably a "good sunk cost" (mostly
future-proof, even with let becoming like let* not hoisted to block top). I doubt people
will rewrite to var (which requires careful analysis to avoid collisions where there used
to be shadowing). They simply won't use strict mode.
But const or let, the idea that "use strict" is so attractive it will cause
re-sinking sunk costs seems farfetched to me. We'll find out, though, because I do agree
we should make Firefox's strict mode ban let, const, and function in block for now. I
hope JSC and V8 do likewise with their IE-workalike function-in-block extension.
It's a judgment call, and I'd take these on a case-by-case basis. For const
and let, I see little harm in browsers allowing them now in strict mode with
the purely non-hoisting (C++-like) scoping rules, particularly if they
complained when you accidentally declared a variable twice directly in the same
block.
The main risk is avoiding silent changes to code behavior. Code which used to
be an error but becomes valid or which used to be an extension but becomes an
error are easier to deal with. Thus an implementation that hoisted a const to
the top of the block but had a barrier preventing you from using it above the
declaration would be ok in practice (causing silent behavior changes very
rarely), while one that also hoisted the const initialization to the top of the
block without a barrier would be bad.
Waldemar
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
