constructor, super, and data members issue

[Isiah Meadows]

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/751fb678/attachment.html>