Yeah, I was more focused on the static class side of things, because I thought they were referring to that. Class instance fields are different, and so of course, those are never set on the prototype unless for whatever reason, the parent constructor returns `Object.getPrototypeOf(this)` instead of letting it default to the normal `this`.
My bad, and you are correct. ----- Isiah Meadows [email protected] www.isiahmeadows.com On Sun, Aug 26, 2018 at 12:20 PM Logan Smyth <[email protected]> wrote: > > Static class fields run their initializers and define the properties at > declaration time, and class constructors have the parent class as the > `[[Prototype]]`, so static field values are inherited. I think this is adding > to confusion though, because while that's absolutely true, that is not > applicable in the same way to non-static class fields, which is what this > original email is focused on. You could indeed also address this with static > properties in a proper ES6 environment as > ``` > class Base { > static idAttribute = "id"; > > constructor() { > this.idAttribute = new.target.idAttribute; > } > } > class Derived extends Base { > static idAttribute = "_id"; > > constructor() { > super(); > } > } > ``` > > On Sun, Aug 26, 2018 at 10:35 AM Isiah Meadows <[email protected]> wrote: >> >> Every object, including functions, have an internal prototype. Functions >> normally have one set to `Function.prototype`, and objects normally inherit >> from `Object.prototype` at least indirectly. But because of how prototypes >> work, the only requirement for something to be used as a prototype is that >> it must be an object. So you can do `Object.create(someFunction)` and >> although you can't call it (it's not a callable object), that object >> inherits all the properties and methods from that function. `class` in >> JavaScript is just sugar over a common pattern (really complex sugar >> requiring `new.target` to emulate, but still sugar), not an entirely new >> concept, and it all builds off of prototypes. Specifically, the instance >> prototype inherits from the parent prototype, and the class constructor >> itself inherits from the parent constructor. That's why if you declare a >> static `call` method on a parent class, you can still access and use it in >> the subclass. >> On Sat, Aug 25, 2018 at 19:58 Ben Wiley <[email protected]> wrote: >>> >>> 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
