Decorators and inheritance

[miguelcobain]

How would decorators play along with class inheritance? Would it be worth mentioning it in the document?

[sebmck]

What's ambiguous with decorators and how inheritance is handled?

[miguelcobain]

Example: when we override a method, do we expect it to inherit the superclasses method decorators?

class Animal {
  @transport
  move() {
  }
}

class Cat extends Animal {
  move() { //has this method @transport decorator?
  }
}

I can provide a more sensible example if needed.

[sebmck]

The new descriptor would shadow the super one. Descriptors can be modified (it's the point of decorators) so it's impossible to track for inheritance.

[miguelcobain]

It would be good to have the super class decorators applied to the concrete bottommost method, "incrementally" changing the descriptor with all decorators. Is this nonsense?

My knowledge in descriptors is a bit limited, that's why I shouldn't talk too much about decorators. :smile:

[sebmck]

You can't track where the original value is so you can't inherit descriptors.

function foo(target, name, descriptor) {
  var value = descriptor.value;
  descriptor.value = function () {
    return "whatever"; // we could do something with `value`
  };
}

class Foo {
  @foo
  foo() {}
}

You have no idea where the original method is and how it's going to be used so you can't swap it out.

[miguelcobain]

You mean that from the @foo decorator implementation we can't access the original foo() {} class function?

[sebmck]

You can't track where the original method is so you can't "replace" it.

[silkentrance]

Close, invalid?