`static` keyword from C/C++ as own closured var declaration
allen at wirfs-brock.com
Tue Nov 23 15:18:45 PST 2010
Waldemar has good questions, most of which would be addressed in a full
proposal. But some off the cuff answers are embedded below
From: Waldemar Horwat
Sent: Tuesday, November 23, 2010 1:07 PM
Cc: es-discuss at mozilla.org
Subject: Re: `static` keyword from C/C++ as own closured var declaration
This was already discussed at the September meeting. Some interesting
- How far does "static" hoist? One let-scope? One block-scope? One
function-scope? One class-scope?
AWB: the simple answer would be one block-scope (isn't that the same as a
let-scope??). It probably will take some experimentation to verify that the
simple solution has reasonable use cases. If not, function scope may be more
appropriate. Until and unless we have class declarations there really isn't
anyway to consider class-scopes.
- Refactoring by adding or removing a scope becomes quite error-prone.
AWB: Just as it is for function and var declarations. Function scoping
static might actually alleviate refactoring issues.
- To avoid breaking refactoring, you'd need to allow "static static",
"static static static", etc.
AWB: ?? examples?? BTW, isn't it the job of refactoring tools to address
always be restricted to dump editors.
- In what scope do you look up the initializer expressions? What if they
reference variables that were shadowed in between the scope where they're
actually present and the one into which they got hoisted?
AWB: The scope surrounding the construct they are hoisted out of (either
block or function depending upon the first design decision). If that sort
of shadowing is actually possible, it should be an early error if it
actually occurs. Also need to consider whether initializer expressions can
reference other statics in the same scope.
- When do the initializers run? What if it's a static const?
AWB: Before entering the scope it is hoisted out of. For function scope
this would be specified as part of "variable instantiation". static const
behavior has same scope-hole rules as regular const.
- What happens if you have two of the functions above, each trying to hoist
its own "x" into the same scope? Under which conditions do the x's stay
separate, and under which ones do they become the same variable?
AWB: They are always separate. Each function gets its own static scope that
exists between the function and its enclosing scope. This is illustrated in
Bga's "ES3 way" desugaring.
es-discuss mailing list
es-discuss at mozilla.org
More information about the es-discuss