constructor, super, and data members issue

[Ben Wiley]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180825/c1b8c511/attachment.html>