Discuss
  • Fwd: Moving forward with function decorators

Fwd: Moving forward with function decorators

# Андрей Губанов (5 years ago)

Here I described my thoughts about this topic 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 expressions 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");

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!
# Michael Luder-Rosefield (5 years ago)

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.

# Андрей Губанов (5 years ago)

Class member decorators are there: 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.