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:
@decoratorA({
// maybe 1-100 lines
})
@decoratorB({
// 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):
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. Thanks!
For your consideration.
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:
I would like to prose an inline alternative syntax that would be equivalent to the above:
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):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. Thanks!