Some obvious ones: - they defineProperty instead of set (matters for setters on the proto) - x; produces undefined vs. a hole
-
-
both of these can easily affect what happens when you subclass an object in pretty common ways.
1 reply 0 retweets 2 likes -
So if I do this.x=2 in base ctor, & extend, & in sub class do a x = 3 field, latter will defineProperty on proto & be shadowed by base x?
1 reply 0 retweets 0 likes -
Replying to @AdamRackis @rwjblue
Fields are never on the proto. The issue is class X { set x() {} } class Y extends X { x = 1; } ^ doesn't run X's setter in Stage 3.
1 reply 0 retweets 6 likes -
Ahhhhh - seems like a bug in the earlier proposal. Glad it was fixed.
1 reply 0 retweets 2 likes -
Honestly seems pretty esoteric—unlikely to matter usually. Given react's JS-first, class fields were pretty necessary over manual binding
2 replies 0 retweets 0 likes -
Replying to @AdamRackis @rwjblue
class MyInput extends HTMLInputElement { type = "text"; } doesn't do what you think it does.
1 reply 0 retweets 2 likes -
So class fields are purely to create new properties, not sure ctor initialization.
1 reply 0 retweets 0 likes -
Replying to @AdamRackis @rwjblue
Anyway, it's fine. You've been able to use Babel's field transform in Ember if you want for ages. Ember itself has a higher stability bar.
1 reply 0 retweets 2 likes -
Guess I just don't grok what "Ember itself" means - you talking about core contributors not being able to use these js features?
3 replies 0 retweets 0 likes
There's questions like: how do computed properties work with classes. Similar in react: how does PureComponentMixin work
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.