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".

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".

> 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".