How can they be prototypically inherited if they don't live on the prototype? I feel like I'm missing something.
Le sam. 25 août 2018 19 h 53, Isiah Meadows <[email protected]> a écrit : > 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
