constructor, super, and data members issue

[Ben Wiley]

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 <isiahmeadows at gmail.com> 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 <therealbenwiley at gmail.com> 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 <augusto.borgesm at gmail.com>
>> a écrit :
>>
>>> 24-08-2018 19:29, Aaron Gray <aaronngray.lists at gmail.com>:
>>>
>>> >
>>> > 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 <ljharb at gmail.com>:
>>>
>>> >
>>> > 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
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180825/fc4b3ef5/attachment-0001.html>