What about decorators?

[allenwb]

This proposal does not take any stand with respect to the Decorators Proposal and is largely orthogonal to it.

The basic mechanisms of decorators are still applicable to class definitions as extended by this proposal. However, the details of the decorator API would have to evolve to account for the different set of class element declarations introduced by this proposal.

One concern for users of decorations may be that there doesn't appear to be any way to decorate a list of identifiers to provide generative behavior. One way to address this would be, as part of generator support, to provide an additional kind of class body element that is simply a decorated list of IdentifierName but that no standard semantics other than decorator application. For example:

function nop() {};  //a decorator function that does nothing

class C {
  @nop x, y, z; //this does nothing
  @xyzzy a;     //throws if xyzzy is undefined
  @own  p, q;  //might be used to declare public own instance properties
  @publicRead
   var n;  //generate a read accessor method for instance variable n
}

[wycats]

I'm not so sure that decorators are as orthogonal as this issue implies.

Having worked on decorators for quite some time now, it's clear to me that the current class suite co-evolved with decorators: many aspects of the design were fine-tuned with specific use-cases designed to be expressed via decorators.

On the one hand, when we attempted to integrate decorators into previous features, we always found aspects of those features that needed to be changed in order to accommodate decorator use-cases. On the other hand, we often found that we could strip down some desired "bells and whistles" from earlier proposals (e.g. protected) through better extensibility, but only but carefully thinking through the semantics of decorating the more minimal set of constructs.

In the past, I found it very useful that @littledan took the time to illustrate, even relatively early in the process, how theoretical (but fleshed out) decorators could be used to close the gap on those use-cases. Some of the examples from those exercises made it into the current draft of the decorator proposal, and I think it would be very helpful to get a sketch of what those examples would look like with a hypothetical decorator extension to this proposal.