5: But as an Ember developer myself, I have appreciated the stability of a working, featureful object model while ES2015 classes fleshed out
-
-
both of these can easily affect what happens when you subclass an object in pretty common ways.
-
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?
-
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.
-
Ahhhhh - seems like a bug in the earlier proposal. Glad it was fixed.
-
Honestly seems pretty esoteric—unlikely to matter usually. Given react's JS-first, class fields were pretty necessary over manual binding
-
class MyInput extends HTMLInputElement { type = "text"; } doesn't do what you think it does.
-
So class fields are purely to create new properties, not sure ctor initialization.
-
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.
- 2 more replies
New conversation -
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.