Inline class decorators suggestion

Don Griffin don at sencha.com
Tue Oct 4 20:45:55 UTC 2016


Hi Andy,

Thanks for the pointer. I'll head over there.

My suggestion here is a fix for the inconsistency specifically with class
decorators and the class keyword... That is that the contents of a class go
inside the class body :) Some decorators as I've suggested are simply ways
to add content to the class and these tend to be quite lengthy.

I agree this suggestion is not consistent with other forms of decorator
usage. I don't see the conflict you are suggesting with method parameters,
though.

In this suggestion there is no argument-less aspect to consider.
Argumentless class decorators still go above the class. That location is
aesthetically pleasing when it is a decoration not an obfuscation... as is
the case when you have hundreds of lines of decorator statements and no
content to the class body itself. imho and all :)

Thanks for feedback!

Best,
Don
--
Don Griffin
Director of Engineering
Sencha, Inc.

On Tue, Oct 4, 2016 at 3:31 PM, Andy Earnshaw <andyearnshaw at gmail.com>
wrote:

> This breaks consistency with other decorator proposals, where the
> decorator precedes the decoratee. Also remember that decorators don't have
> to take parameters:
>
> ```
> // Issues a warning on instantiation
> @deprecated
> 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:
>
> https://github.com/wycats/javascript-decorators
>
> On Tue, 4 Oct 2016, 19:39 Don Griffin, <don at sencha.com> wrote:
>
>> Greetings!
>>
>> 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 (http://docs.sencha.com/extjs/
>> 6.2.0/classic/Ext.Class.html).
>>
>> 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):
>>
>>     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.
>>
>> Thanks!
>>
>> Best,
>> Don
>> --
>> Don Griffin
>> Director of Engineering
>> Sencha, Inc.
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161004/d4433d37/attachment-0001.html>


More information about the es-discuss mailing list