The first question maybe in all these discussions is what is needed or
not (in real life).
In BTF discussions I gave an example where (surprisingly) for an app
there were a very few prototype like declarations.
Because I just did not need it for this app.
The second question is maybe whether ES is designed for frameworks or
apps, I will go for the second one, apps do not necessarly need
frameworks, libraries, etc, and frameworks do help developers not to
understand what they are doing
Then adding classes or such looks to complicate more things while
existing prototype behavior is good
Maybe the focus should be put more on performances
Le 17/03/2012 00:22, Brendan Eich a écrit :
Mark S. Miller wrote:
I agree with Waldemar. Classes aside, since code like
{
//...foo...
let x = 3;
function foo() { return x; }
//...
}
is statically legal, and is only wrong if foo is called before x is
initialized, the dynamic dead zone is very valuable. Otherwise, the
call to foo() silently proceeds with a meaningless result.
If you'd really rather have silent meaninglessness, use "var" instead
of "let".
Classes are sugar for objects with properties, though -- rememeber, we
agreed to sugar the protoypal pattern, not the closure pattern.
A declared variable binding is different from an object property. They
aren't the same thing.
And properties can be used before initialization in JS today (and in
Dart -- you Google guys are not all following the same rules :-P).
It seems to me you're not agreeing or disagreeing with anything about
classes as prototypal sugar, rather you're trying to reason about
properties by pointing to let binding rules. Last July I flagged
classes as subject to conflict and confusion in TC39 due to this
declaration vs. property conflation. If we can't agree to avoid it by
letting properties by properties, then classes are indeed "out" for
ES6 -- and out of Harmony for now.
/be
On Fri, Mar 16, 2012 at 3:50 PM, Brendan Eich <[email protected]
<mailto:[email protected]>> wrote:
Brendan Eich wrote:
We can defer these by deferring guards and const instance
properties, and tried to do so. But IIRC at least Waldemar was
not happy leaving writable instance properties usable (with
default value undefined) before being initialized.
Of course, Dart allows this and discloses null on use before
initialization:
class Foo {
var a;
Foo(a) {
print(this.a);
this.a = a;
}
}
main() {
var foo = new Foo(42);
print('main: ' + foo.a);
}
Tested at http://dartlang.org/.
/be
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : [email protected]
Web : www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
