8 comments

[ 3.2 ms ] story [ 25.4 ms ] thread
It is not precisely clear decorators will make it into ES2016 yet (maybe ES2017?). That is why it is better to say ES Next or something like that.
It's specifically a proposal for 2016, and described as such in the very first sentence.

ES Next doesn't exist.

Also: A decorator in Python does not necessarily return the same function it received.
I sure hope all these extensions will not bring down the raw performance of various javascript engines.
"A decorator is just an expression that will be evaluated and has to return a function." It seems to me that it's just sugar for wrapping functions... is there some reason that couldn't be optimized?
In Python, the decorator syntax is literally just syntactic sugar.

This:

    @some_decorator
    def some_func():
        pass
Is equivalent to this:

    def some_func():
        pass
    some_func = some_decorator(some_func)
It seems like only methods can be decorated. Is there any hope for decorators on top-level functions in the future?
Unfortunately, due to hoisting decorating top-level functions is a real pain [1].

What should the behavior of:

    myMagicFunction();

    var myDecorator = require('myDecorator');

    @myDecorator
    function myMagicFunction() {
      // TODO: Make magic
    }
be?

- `myDecorator`'s require statement is hoisted above `myMagicFunction`'s declaration so that `myMagicFunction` is always decorated? (Results in a given `var`'s behavior changing depending on whether it is invoked as a decorator, an exceedingly non-obvious behavior)

- Function hoisting doesn't happen for decorated functions (non-obvious, possibly hard to implement).

- Function hoisting happens but the decorator is not hoisted (resulting in a sometimes-decorated function).

These problems don't admit of a simple solution (at least as far as I can see).

  [1]: https://github.com/wycats/javascript-decorators/issues/4