Thanks for the test examples. They point out that there are situations that
need to be dealt with that don't naturally arise if a programmer writes code
using the basic desugaring previous suggested. However, I don't seen
anything that is insurmountable in terms of defining the semantics. It also
points out that in general we may not get away with just saying syntax x
desugars into form y. You have to consider what static semantic
expectations that the use of syntax x is likely to create for the programmer
and deal with those expectations.
More specific responses marked with AWB below.
Allen
-----Original Message-----
From: Waldemar Horwat
...
It's substantially worse here. If we adopt block-scope, we get:
function f(b) {
if (b)
return 43;
static x = 1;
return x++;
}
If we adopt the block-scope recommendation, refactoring it to:
function f(b) {
if (b) {
return 43;
} else {
static x = 1;
return x++;
}
}
will do something completely different.
AWB: I don't see how this is substantially different from the same issue
using block scoped let. When adding or removing block levels you have to
pay attention to whether you are including or excluding existing
declarations in the block. This is the sort of thing that refactoring tools
are supposed to help with.
--------
- 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
issues like this. We shouldn't assume that JavaScript programmers will
always be restricted to dump editors.
See example above. The local way to fix the refactoring is to turn it into:
function f(b) {
if (b) {
return 43;
} else {
static static x = 1;
return x++;
}
}
The same issue arises if we make a different decision on how far "static"
hoists, but the examples are slightly bigger.
AWB: and you could also do the same for let let but I don't think anybody
would seriously propose that. A good refactoring tool will tell you if a
refactoring is changing the semantics. A better one would place the
declaration at the appropriate block level to maintain the previous
semantics.
-----------
...
- 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.
I asked about static const because now you have the new problem of multiple
entry into the scope that does the const initialization.
AWB: See example A below, and assume that "static const x" is just like
"static x" except that no assignments to x are allowed other than by the
initializer. The static const would still be hoisted and evaluated in order
with the initializer using the static scope as the current environment when
evaluating the initialization expression, just like for non-const static.
It's all still linear.
------
- 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.
So what should the following examples do?
A.
function f() {
x = 3;
static x = 2;
return x;
}
AWB: The simplest desugaring would yield 3:
let f = function() {
let x=2;
return function f() {
x=3;
return x;
}();
}
However, it would arguably be better to require that any use of x in f must
come after its static declaration statement. In that case, A would produce
an early error.
-----------
B.
function f() {
let x = 3;
static x = 2;
return x;
}
AWB: should be an early error, can't declare a variable as both a static and
a non-static in the same scope.
---------
C.
function f() {
static x = 3;
static x = 2;
return x;
}
AWB: I'd also make this be an early error
-------
D.
function f(b) {
if (b) {
static x = 1;
return x++;
} else {
static x = 1; // Same x or different?
return x++;
}
}
AWB: depends on the basic function/block scoping decisions. If block scoped
statics then they are different x's.
--------
Waldemar
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
