Class fields are prototypically inherited just like via `Object create`. This is more useful than you might think, and it's the main reason anyone actually cares about static fields beyond namespacing. On Sat, Aug 25, 2018 at 14:36 Ben Wiley <[email protected]> wrote:
> All this just reminds me of *my opinion* that class fields is a borrowed > concept from statically typed languages that is misplaced in a dynamically > typed languages like JavaScript. > > In C++ I use class fields to declare what properties will be allocated and > instantiated when a new class member is constructed. > > In the ES proposal for class fields we mimic this type of behavior by > instantiating properties on the object when it's constructed, but there's > no runtime guarantee that this set of properties will remain the same. > > There's no reason not to put this in the constructor, and although putting > class fields on the prototype is debatably not the best idea, it would be > the only scenario where we get some kind of new helpful behavior out of it. > > Ben > > Le sam. 25 août 2018 14 h 25, Augusto Moura <[email protected]> a > écrit : > >> 24-08-2018 19:29, Aaron Gray <[email protected]>: >> >> > >> > Yeah it does look like its badly "broken by design". >> > >> >> Why this behaviour is broken? Every OOP language that I worked with >> behaves de same way, and there's not many developers complaining about >> it. If you want to use a property that might be overrided in a >> subclasss you need to use a method and make the source of the data >> more versatile (in Java and others similiar languages we have to >> implement it using getter methods). Luckily Javascript doesn't need >> getter and setters methods to make a property overridable because of >> getter and setters descriptors, so we can workaround the first example >> easily: >> >> ``` js >> class Bar { >> bar = 'in bar'; >> >> constructor() { >> console.log(this.bar) >> } >> } >> >> class Foo extends Bar { >> _initiedSuper = false; >> _bar = 'in foo'; >> >> constructor() { >> super(); >> this._initiedSuper = true; >> } >> >> get bar() { >> return this._bar; >> } >> >> set bar(val) { >> if (this._initiedSuper) { >> this._bar = val; >> } >> } >> } >> >> new Foo(); // will log 'in foo' >> ``` >> >> *I have to say the relaying that the super constructor will use the >> bar property and workarounding it **is a bad practice** and should be >> avoided at any costs. The contract with the super class constructor >> should rely only on the super call, these situations just reveal bad >> design choices in the super class. Logan Smyth example is the correct >> answer to this problem* >> >> >> 25-08-2018 01:28, Jordan Harband <[email protected]>: >> >> > >> > Personally I think a design where the superclass relies on any part of >> the >> > subclass is "broken by design"; but certainly there's ways you can >> achieve >> > that. >> > >> >> Of course is not broken. The super class has a contract with a >> parametrized option, it can be used in subclasses or just in a >> constructor call `new Base({ idAttribute: 'foo' })`, if it has a >> default value for that is not a sub class concern. When refactoring >> code adding defaults and "lifting" parameters are very common ~not >> only on OOP~ and relying that the super class is using some property >> in the constructor is the real "broken by design". >> _______________________________________________ >> 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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
