Suggestion on Decorators requiring initialization (Opt A)

[k1r0s]

First of all I have to say that I really like the direction we're heading with the latest proposal. I swear I had more time to check this more deeply.

I was looking at this https://github.com/tc39/proposal-decorators#method-decorators-requiring-initialization-work

And I though a better sample can be provided which better defines what is syntactically possible with decorators being finally a function call (which I really love)

class MyElement extends WithActions(HTMLElement) {
  @on('click') clickHandler() { }
}

vs this

@Events
class MyElement extends HTMLElement {
  @Events.on('click') clickHandler() { }
}

Don't take me wrong. I just see this option better explains what developers actually need to implement in order to attach Events which shouldn't be related with inheritance "grammarwise" because we're wrapping or replacing a behavior and not necessarily (emphasis) extending the whole class.

Anybody can arguably dismiss Opt A since it requires the developer to use two interfaces to alter the class in non obvious ways by using inheritance and a decorator, but none of this interfaces can't be used separately, or can it be? If these interfaces must be used together we better define them in the same namespace, don't we.

wrapping up I just think this proposal better defines decorator capabilities (as a language feature) and makes more easy to explain to newcomers.

feedback appreciated!

Thanks for the hardwork!

[pzuraq]

I believe this is no longer relevant because decorators can now add initializers via addInitializer, so I'm going to close this. Feel free to reopen if you feel that's not the case!