Luke Hoban wrote:
On May 22, 2012, at 9:29 AM, Erik Arvidsson wrote:
I think this proposal has one fatal flaw and that was what brought it
down the last time we had a proposal which used the same concepts.
Given:
class C(x) {
public method() {
return x;
}
}
It seems like the arguments to the constructor are in scope for the
entire class body when they really aren't. The above would raise an
error that "x is undefined".
This is indeed a valid concern, though I don't see it as a fatal
flaw. It's effectively the same issue that statics would pose if
added to any existing class proposal.
One way to address this concern is to put 'x' in scope in the method
bodies, but as a poisoned reference that raises an (early?) error.
That helps ensure that unexpected outer variables are not
unintentionally captured.
Oh no, it's better to define static constraints that methods can not see
into constructor's locals (args or let/vars).
And fail-fast when such constructor function is defined.
The code above would be rewritten:
class C(public x) {
public method() {
return this.x;
}
}
On the other hand - this allows a sufficiently simpler representation of the
class than the max/min proposal:
class C {
constructor(x) {
this.x = x;
}
public method() {
return this.x;
}
}
This is not exactly fair comparision, because there are other shortcut
constructor proposals, so it is more:
class C(public x) {
public method() {
return this.x;
}
}
against
class C {
constructor(this.x) {}
public method() {
return this.x;
}
}
Luke
As I told in different mail, I see no reason to use "class" - this is
just an augmented function syntax. The function keyword is, after all,
the one that creates constructor functions (and mainly those, in ES6
with arrows).
I would be for this, if it gets through, but _only_ if it will use plain
old function keyword.
Herby
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
