Inline class decorators suggestion

Andy Earnshaw andyearnshaw at
Tue Oct 4 20:31:48 UTC 2016

This breaks consistency with other decorator proposals, where the decorator
precedes the decoratee. Also remember that decorators don't have to take

// Issues a warning on instantiation
class Foo {

If the decorator goes inside the class declaration, it conflicts with
method parameters.

Probably the right place for discussion is on the proposal report though:

On Tue, 4 Oct 2016, 19:39 Don Griffin, <don at> wrote:


Greetings! I work at Sencha and we have spent considerable time in recent
months deciding how we will use decorators and how they could replace the
various aspects of our Ext JS class system (

Because these features are class-level concerns, we are seeing this
unfortunate pattern emerge:

        // maybe 1-100 lines
       // another long thing (maybe some html template)
    class MyComponent extends Component {
        // empty? yes... often!

I would like to prose an inline alternative syntax that would be equivalent
to the above:

    class MyComponent extends Component {
        @decoratorA {
            // maybe 1-100 lines

        @decoratorB {
           // another long thing (maybe some html template)

Basically a decorator name followed by an object literal. This maintains
the aesthetic flow of describing the contents of a class within its body
and does not "bury the headline" so to speak (that a class is being
declared here).

You could see the benefits of this approach better with some simple
decorators like `@internal` (a debug aid to detect accidental name
collisions) or `@statics` (for better compression) or `@prototype` (to put
data on the class prototype):

    class MyComponent extends Component {
        @statics {
            create () { ... },
            // many more static methods

        @prototype {
             answer: 42,
             defaultText: 'Hello world'

        @internal {
            deepThought () { ... },
            moreDeepThoughts () { ... }

For what it's worth, you see this same top-heavy class pattern in Angular 2
as well. The large numbers of lines above the class keyword marginalize the
class statement.

I look forward to your thoughts.

If this is not the right place to post suggestions, apologies in advance
and I would greatly appreciate a pointer to the proper place.


Don Griffin
Director of Engineering
Sencha, Inc.

es-discuss mailing list
es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list