andrey.a.gubanov at gmail.com (2019-09-04T11:25:02.298Z)
Class member decorators are there: https://github.com/tc39/proposal-decorators Object method decorators: of course they do make sense but honesty I don't know do they need to be also included as a part of "function decorators proposal"? They look and behave very similar to class member decorators. In other words their decorators also need to accept [target, property, descriptor] and return the descriptor.
andrey.a.gubanov at gmail.com (2019-09-04T11:24:49.131Z)
Class member decorators are there: https://github.com/tc39/proposal-decorators Object method decorators: of course they do make sense but honesty I don't know do they need to be also included as a part of "function decorators proposal"? They look and behave very similar to class member decorators. In other words their decorators also need to accept [target, property, descriptor] and return the descriptor.
Class member decorators are there: https://github.com/tc39/proposal-decorators Object method decorators: of course they do make sense but honesty I don't know do they need to be also included as a part of "function decorators proposal"? They look and behave very similar to class members. In other words their decorators also need to accept [target, property, descriptor] and return the descriptor. ср, 4 сент. 2019 г. в 14:04, Michael Luder-Rosefield <rosyatrandom at gmail.com >: > I don't see any mention of class/object shorthand methods; would these be > trivial, do you think? > > ``` > class FooClass { > @dec1 @dec2 > bar () { } > } > > const fooObj = { > @dec1 @dec2 > bar () { } > } > ``` > -------------------------- > Dammit babies, you've got to be kind. > > > On Wed, 4 Sep 2019 at 11:49, Андрей Губанов <andrey.a.gubanov at gmail.com> > wrote: > >> Here I described my thoughts about this topic >> https://github.com/finom/function-decorators-proposal. The main idea of >> moving forward with function decorators is to make them behave like there >> were defined and wrapped by another function, not more, and get rid of any >> hoisting when they're used. >> >> Function expression and arrow functions >> >> const foo = @decorator1 @decorator2 function bar() { return "Hello" } >> // Will become: >> const foo = decorate([decorator1, decorator2], function bar() { return "Hello" }); >> >> And >> >> const foo = @decorator1 @decorator2 () => "Hello" >> // Will become: >> const foo = decorate([decorator1, decorator2], () => "Hello"); >> >> >> <https://github.com/finom/function-decorators-proposal#function-declarations>Function >> declarations >> >> And this is the most important. I propose to make a decorated function >> declaration behave as let definition. >> >> @decorator1 @decorator2 function foo() { return "Hello" } >> // Will become: >> let foo = decorate([decorator1, decorator2], function foo() { return "Hello" }); // no hoisting! >> >> _______________________________________________ >> 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/20190904/09860461/attachment.html>