Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow decorators for functions as well #4

Open
svieira opened this issue Mar 18, 2015 · 66 comments

Comments

Projects
None yet
@svieira
Copy link

commented Mar 18, 2015

Decorators for classes, methods, and object properties are a really nice extension to the language. The only extra one I would like to see is the ability to add decorators to function declarations:

@RunOnce
function expensiveOperation() {
    return 1 + 1;
}

de-sugars to:

var expensiveOperation = RunOnce(function expensiveOperation() {
  return 1 + 1;
});

This suggests allowing decorators for any assignment, but I think that might be a bit much so I'm leaving it out of this PR:

// For the curious, that would allow constructs like this
@RunOnce
let expensiveOp = () => 1 + 1

// De-sugars to

let expensiveOp = RunOnce(() => 1 + 1);
@sebmck

This comment has been minimized.

Copy link

commented Mar 19, 2015

The issue with adding decorators to function declarations is that they're hoisted which means hoisting the decorators too which changes the position in which they're evaluated.

@svieira

This comment has been minimized.

Copy link
Author

commented Mar 19, 2015

True, and that is a potential foot-gun, but I cannot think of any cases where source position is likely to be needed at run-time (I can see using decorators as targets for compile-time transformations using sweet-js, but in those cases the function hoisting behavior does not apply.) As I understand it, hoisting is likely to (though not specified to) happen in order, so even if you had a stateful decorator that added each decorated function to a queue, the functions would still run in order.

Am I just being dense and missing an obvious use case where source position could make or break functionality?

@sebmck

This comment has been minimized.

Copy link

commented Mar 19, 2015

Some examples:

var counter = 0;

var add = function () {
  // this function isn't even accessible if the decorator evaluation is hoisted
  // ie. done before `var counter = 0;`
  counter++;
};

@add
function foo() {

}

// what is the value of `counter`?
// if it's hoisted then it would be 2 when logically it should be 1

@add
function foo() {

}
var readOnly = require("some-decorator");

// is the evaluation hoisted?
// if so `readOnly` wont be defined if not then any reference to `foo` before the
// decorator will get the bare function
@readOnly
function foo() {

}

The behaviour is non-obvious and it's impossible to sprinkle to get obvious behaviour. It's similar to class declarations not being hoisted because their extends clause can be an arbitrary expression.

@svieira

This comment has been minimized.

Copy link
Author

commented Mar 19, 2015

Chuckles Fair enough - thanks for taking the time to point out the issues!

@svieira svieira closed this Mar 19, 2015

@andreypopp andreypopp referenced this issue Mar 21, 2015

Closed

Question #5

@nmn

This comment has been minimized.

Copy link

commented Apr 9, 2015

The noted problems here suggest to me that decorators are possibly going to have very much the same problem as operator overloading is supposed to have.

The major concern I have with decorators is people writing too many decorators with not very good names. Or even for things that are pretty complicated. The concern I have is that decorators are only syntactic sugar to make code more declarative. But I hope they won't end up creating code that is often misleading and full of surprises.

I personally don't think any feature's merits should be judged by considering the worse use-cases. But I think it's still interesting to think about them to remove as many footguns as possible.


Relevant Point: Perhaps, functions decorators SHOULD work for functions. But since hoisting is the problem, Hoisting could be disabled for any function that is decorated. Since Function assignments work the same way, I don't think its too confusing.

@sebmck

This comment has been minimized.

Copy link

commented Apr 9, 2015

@nmn

But since hoisting is the problem, Hoisting could be disabled for any function that is decorated. Since Function assignments work the same way, I don't think its too confusing.

It is confusing. Function declarations that are hoisted sometimes isn't going to cut it.

@nmn

This comment has been minimized.

Copy link

commented Apr 9, 2015

@sebmck Fair point.

Thinking about it more, perhaps they are no so important for functions.

Functions that take take and return functions are pretty easy to write. They are more useful in classes as the syntax keeps things from getting hairy.

Thanks.

@Ciantic

This comment has been minimized.

Copy link

commented Apr 17, 2015

Why are they not important for functions? Memoize is just as needed in functions as well as in classes. Also for currying, who doesn't curry their functions ;)

If problem is you can accidentally use class decorators in functions, maybe another syntax:

@@memoize
function something() {
}

double at, or something.

Edit: Is hoisting really a problem? Being used Python a lot which implements function decorator, I don't think the order of decoration is used to anything except in bad code, which is really hard to safeguard anyway.

@sebmck

This comment has been minimized.

Copy link

commented Apr 17, 2015

@spleen387 Hoisting is still a problem.

@nmn

This comment has been minimized.

Copy link

commented Apr 17, 2015

first a question: do generator functions get hoisted? If not isn't that confusing as well.

If yes, there is already a proposal for making custom wrappers around generators, like async functions.

async function x(){}
// becomes
function x(){
  return async(function*(){
    ...
  })()
}

How does this proposal deal with hoisting?

@nmn

This comment has been minimized.

Copy link

commented Apr 17, 2015

Another approach, let the function get hoisted. But the decorator should be applied where it is defined.

So this:

var readOnly = require("some-decorator");

@readOnly
function foo() {

}

will desugar (and hoist) to:

function foo() {
}
var readOnly = require("some-decorator");

foo = readOnly(foo)
@sebmck

This comment has been minimized.

Copy link

commented Apr 17, 2015

Generator function declarations are definently hoisted. Hoisting the
function declaration and not the decorator is unintuitive and confusing.
You can just wrap the function in a method call and it expresses the exact
same thing without the confusing semantics.

On Friday, 17 April 2015, Naman Goel notifications@github.com wrote:

Another approach, let the function get hoisted. But the decorator should
be applied where it is defined.

So this:

var readOnly = require("some-decorator");

@readonly
function foo() {

}

will desugar (and hoist) to:

function foo() {
}
var readOnly = require("some-decorator");

foo = readOnly(foo)

Reply to this email directly or view it on GitHub
#4 (comment)
.

Sebastian McKenzie

@nmn

This comment has been minimized.

Copy link

commented Apr 17, 2015

@sebmck I just updated my first comment. How does compositional functions deal with hoisting?

You can just wrap the function in a method call and it expresses the exact same thing without the confusing semantics.
I get that, but the same could be said about classes as well.

I don't like the idea of decorators for only classes, and I'm just trying to find a solution to the hoisting problem. I feel like having decorators for only classes makes the language more disjointed and inconsistent than it already is.

@sebmck

This comment has been minimized.

Copy link

commented Apr 18, 2015

I get that, but the same could be said about classes as well.

Classes don't hoist so they don't suffer from the same problem that disallow function declaration decorators.

I don't like the idea of decorators for only classes, and I'm just trying to find a solution to the hoisting problem.

This isn't an intuitive solution to the hoisting problem and whatever solution is going to be an extreme hack.

@nmn

This comment has been minimized.

Copy link

commented Apr 18, 2015

This isn't an intuitive solution to the hoisting problem and whatever solution is going to be an extreme hack.

In that case, perhaps decorators aren't a great idea after all? Wouldn't having decorators for class methods but not normal functions be equally confusing, hacky and inconsistent?

@sebmck

This comment has been minimized.

Copy link

commented Apr 18, 2015

In that case, perhaps decorators aren't a great idea after all?

How are you getting that decorators aren’t a good idea just because you can’t put them on function declarations because of hoisting? An entire feature shouldn’t be nerfed because of one nefarious case.

Wouldn't having decorators for class methods but not normal functions be equally confusing, hacky and inconsistent?

No, because class methods aren’t function declarations.

On Sat, Apr 18, 2015 at 7:51 AM, Naman Goel notifications@github.com
wrote:

This isn't an intuitive solution to the hoisting problem and whatever solution is going to be an extreme hack.

In that case, perhaps decorators aren't a great idea after all? Wouldn't having decorators for class methods but not normal functions be equally confusing, hacky and inconsistent?

Reply to this email directly or view it on GitHub:
#4 (comment)

@nmn

This comment has been minimized.

Copy link

commented Apr 19, 2015

No, because class methods aren’t function declarations.

Fair enough. I still have my reservations, but my intent was only to have a discussion about this.

@ivan-kleshnin

This comment has been minimized.

Copy link

commented Apr 22, 2015

How are you getting that decorators aren’t a good idea just because you can’t put them on function declarations because of hoisting? An entire feature shouldn’t be nerfed because of one nefarious case.

I imagine how people begin to write single method classes only to get decoration feature enabled where basic function could satisfy... While decorator functions can be applied without decorator syntax
that's noisy and inconsistent.

@sebmck you're the best of us aware of ES(any). Any change to kill this hoisting behavior ever? That is hoisting that allows to use undefined vars hiding syntax errors until runtime. Right? Probably the worst JS language aspect 👿

@jamiebuilds

This comment has been minimized.

Copy link

commented Apr 22, 2015

Any change to kill this hoisting behavior ever? That is hoisting that allows to use undefined vars hiding syntax errors until runtime. Right? Probably the worst JS language aspect

There's zero chance of function hoisting ever going away.

I imagine how people begin to write single method classes only to get decoration feature enabled where basic function could satisfy...

Let's explore what a function decorator would be (ignoring hoisting)

function memoize() {
  // do something...
}

@memoize
function myFunc() {
  // do something else...
}

Ignoring the aspect of hoisting, this would be equivalent to:

function memoize() {
  // do something...
}

var myFunc = memoize(function() {
  // do something else...
});

There's no way someone would rather do this:

function memoize(desc) {
  // do something...
  desc.value = value;
  return desc;
}

class MyFuncClass {
  @memoize
  myFunc() {
    // do something else...
  }
}

let myFuncInstance = new MyFuncClass();
myFuncInstance.myFunc();

So yeah we're left with sticking with this:

var myFunc = memoize(function() {
  // do something else...
});

or adding function decorators:

@memoize
function myFunc() {
  // do something else...
}

and because of hoisting function decorators become impossible.

So what's the point of this?

@ivan-kleshnin

This comment has been minimized.

Copy link

commented Apr 22, 2015

@thejameskyle I want to believe something like SaneScript deprecation machinery at compiler level could handle such cases.

@sebmck

This comment has been minimized.

Copy link

commented Apr 22, 2015

@ivan-kleshnin Do you mean behind a directive?

@ivan-kleshnin

This comment has been minimized.

Copy link

commented Apr 22, 2015

@sebmck, yes. I just want to express my opinion that language without at least tiny amount of deprecation process or at least "workaround modes" can't exist forever. Not breaking the web motto sounds good, but complexity grows and grows and we still lack a lot of things... I'm seriously considering to just drop everything and move to ClojureScript or other language which can evolve because it's not bound by backward compatibility craziness. Babel is truly awesome but a lot of things can't be fixed at the transpiler level without serious deviations from ES specs. JS still sucks at enterprise scale. I understand why people continue to use Ruby and other languages on backend.

@yuchi

This comment has been minimized.

Copy link

commented Apr 22, 2015

To solve this a lot of companies enforced the use of function expressions over function declaration.
In fact once you change a function declaration to an expression you get different semantics.

To give this use case more power ES6 now asks the function expression to be named after the variable name.

Also, for succinctness you can go full-arrows here:

const myFunc = memoize(( ) => {
  //
});
@nmn

This comment has been minimized.

Copy link

commented Apr 22, 2015

It's been a very useful discussion.

  1. I agree with @sebmck that the feature should not be nuked for one feature. Honestly it is simpler to wrap functions in functions that classes right now, so decorators are more useful for classes anyway.
  2. However, this discussion is becoming a discussion about succinctness. I think the point of decorators is to make things look more declarative. I would like to argue that passing classes through functions is relatively short to write as well.
  3. I was interested in this: https://github.com/jhusain/compositional-functions
    Generator functions are also hoisted, and it works by making a function that returns a function. So it applies the transformation at call time. I realize that it may not be the best idea for normal functions.
@sebmck

This comment has been minimized.

Copy link

commented Apr 22, 2015

Compositional functions are different as the grammar only allows ImportedBinding:

CompositionFunctionDeclaration :
ImportedBinding [no LineTerminator here] function BindingIdentifier ( FormalParameters ) { FunctionBody }
This means that you can only do import foo from “foo”; foo function bar() {}.

Imports are also hoisted so they’ll be bound before the function declarations are.

On Wed, Apr 22, 2015 at 11:11 PM, Naman Goel notifications@github.com
wrote:

It's been a very useful discussion.

  1. I agree with @sebmck that the feature should not be nuked for one feature. Honestly it is simpler to wrap functions in functions that classes right now, so decorators are more useful for classes anyway.
  2. However, this discussion is becoming a discussion about succinctness. I think the point of decorators is to make things look more declarative. I would like to argue that passing classes through functions is relatively short to write as well.
  3. At this point, I really want to discuss this: https://github.com/jhusain/compositional-functions

Generator functions are also hoisted. So how does it work?

Reply to this email directly or view it on GitHub:
#4 (comment)

@hannahhoward

This comment has been minimized.

Copy link

commented Jun 4, 2015

The recent Angular weekly meeting notes suggests this is up for discussion again. Is it?

@cesarandreu

This comment has been minimized.

Copy link

commented Jul 27, 2015

From what I call tell in #7, it seems like syntax/grammar(?) is still in flux... However, based on babel's current behavior, it kinda sucks that the following works for class declarations and not functions:

import bar from './bar'

// Works
@bar
export class Foo {}

// Doesn't work
@bar
export function foo () {}

Why not allow functions to be decorated by other hoisted values? (i.e. other functions and imports)

@rtm

This comment has been minimized.

Copy link

commented Aug 2, 2015

I'm curious why this issue would have been closed. If one agrees that there is a strong case for decorators, certainly it should apply in equal measure to functions. The current spec is designed to provide decorators for functions, but then says you can have them only if they're members of some class or object.

I'm wondering if there's a bit of anti-function sentiment at work here--something like, "real men use objects and classes and member functions, not wimpy plain old functions", or "in real frameworks like Exxxx everything is an object and since all I really want is syntactic sugar for writing computed properties why do I need decorators on anything other than literal object methods?".

AFAICT the only issue here is hoisting. But to jump from that to saying we can't decorate functions at all seems to be throwing out the baby with the bathwater. If we can't figure out how to have a single, coherent decoration mechanism, we should throw in the towel. The hoisting issue seems to be a red herring to me. For instance, the following code has well-understood, if counter-intuitive behavior:

function foo() {
    console.log(x);    // undefined
    var x = 99;
    console.log(x);    // 1
}

No one would claim that this is obvious, but that's the way the language works. By the same token, one could handle the function/hoisting/decorator case as follows:

function bazify(fn) { fn.baz = 99; return fn; }

function foo() {
    console.log(bar.baz);  // undefined

    @bazify
    function bar() { }

    console.log(bar.baz);    // 99
}

This is no more or less confusing or anti-intuitive than existing behavior from hoisting vars. The effect would be exactly the same as the desugared version below:

function foo() {
  console.log(bar.baz);  // undefined

  function bar() { }
  bar = bazify(bar);

  console.log(bar.baz);    // 99
}

To put it another way, for consistency with current hoisting behavior the decorator would not be hoisted. The decorator would have similar behavior to the initial value in a var statement.

Oops, just noticed this is precisely what @nmn proposed, which seems eminently reasonable.

@lukescott

This comment has been minimized.

Copy link

commented Jan 6, 2016

Shouldn't this:

@foo
export function helper(){}

be this:

export @foo function helper(){}

...or does it matter?

With the hoistability problems, couldn't this:

function foo() {
  console.log(bar.baz); // 99
  @bazify
  function bar() { }
  console.log(bar.baz); // 99
}

be desuggared as:

function foo() {
  var bar = bazify(function bar() { })
  console.log(bar.baz);  // 99
  console.log(bar.baz);  // 99
}

The transpiler would have to change the placement of the declaration to maintain the hoistability. At that point the decorated function is "hoisted". I'm not sure if it's worth the complexity though, or what the edge cases of that would be.

Otherwise if you make the function syntax decorator-able, you either have to choose between not hosting the function at all or hosting the non-decorated function and decorating it in-line (as mentioned by others above).

There is another option: Take the same approach as let:

@bazify function bar() {} // invalid syntax
@bazify func bar() {} // valid, not hoisted
// or (bound this)
@bazify bar() => {} // valid, not hoisted
// or (non-bound this)
@bazify bar() -> {} // valid, not hoisted
// other possible variation of bound this
@bazify func bar() => {}

If this approach is taken function would be left alone and you would have to use a different syntax to declare functions if you wanted to hoist them.

As a side-note, what about this use-case?

var obj = {
  @bazify bar() {}
}
// or
var obj = {
  bar: @bazify function bar() {} // hosting doesn't apply here
}

With above, consistency is also a concern.

@loganfsmyth

This comment has been minimized.

Copy link

commented Jan 6, 2016

@lukescott The value after @ is just an expression, which is evaluated in the current scope. You could just as easily have

function foo() {
  console.log(bar.baz); // 99
  var bazify = function(target, name, descriptor){};
  @bazify
  function bar() { }
  console.log(bar.baz); // 99
}

which with your proposal would then throw because bazify is undefined if the evaluation of the decorator were hoisted. That is the core of the hoisting issue.

@lukescott

This comment has been minimized.

Copy link

commented Jan 6, 2016

@loganfsmyth Ah, gotcha. It could also be this as well (given the current spec):

function foo() {
  console.log(bar.baz); // 99
  function bazify(target, name, descriptor){};
  @bazify
  function bar() { }
  console.log(bar.baz); // 99
}

But still, there is no guarantee a decorator would also be hoisted.

What about the the let approach? Just leave function alone and have another way to declare a function that isn't hoisted that can be decorated.

@calebmer

This comment has been minimized.

Copy link

commented Jan 6, 2016

+1 to the bash/object syntax-ish approach which acts like a let.

@bazify
bar() {
  // Whatever
}

Also, what about expanding variable definitions to support the object-like method syntax?

let foo() {}
const bar() {}
var buz() {}
@calebmer

This comment has been minimized.

Copy link

commented Jan 6, 2016

Is this a blocker for the spec's completion?

@ivan-kleshnin

This comment has been minimized.

Copy link

commented Jan 8, 2016

The thing with def is that it never was a reserved word (like let and const were) so adding it would break a lot of code. So I agree that @RReverser and @calebmer proposition of let or const reusal may be the best alternative. Not sure if spec's would allow that, though.

Arrow functions do not accept this injection which may be a dealbreaker.
Some library APIs depend heavily on this.

// KnexSQL //
// ...
.join(function () {
  this.on(...) // `this` is defined
})

// ...
.join(() => {
  this.on(...) // `this` is undefined
}) 
@cztomsik

This comment has been minimized.

Copy link

commented Jan 14, 2016

I'm curious if decorators are the real way to go - what I want is more compact (kinda backwards) syntax in the hope of more readable code.

Functional programming is very powerful and it can easily get cryptic and hard to explain. I also think this is the reason why are utility-belts (lodash) more successful than real FP libraries - it's easy to teach them even to beginners. My point is that - what if all we need is "rewriting":

@@cache({...})
function hash(str){
  let hash = '';

  ...

  return hash;
}

which would get expanded to:

function hash(str){
  return cache({...}, (str) => {
    let hash = '';

    ...

    return hash
  });
}

What I mean is that instead of returning function in "init-time" the function would get rewritten in a way cache() would get called. This is actually simple function composition but I think it might be easier to understand by newbies while still very valuable.

Unlike decorators, it retains function name and plays nicely with hoisting and named exports. We would loose ability to store function meta-informations but I personally don't believe in magic Angular2 is trying to do.

(I am not sure how would this relate to classes but I can see value in this for functions)

@Macil

This comment has been minimized.

Copy link

commented Jan 14, 2016

@cztomsik That still has the issue that if the decorator isn't hoistable, and the function gets called before the decorator is declared, then you get an exception.

Also many decorator functions (runOnce / memoization cache functions) should be called only once per function decoration, so they can set up some variables in a closure.

@cztomsik

This comment has been minimized.

Copy link

commented Jan 14, 2016

Wouldn't it be possible to throw syntax error if function is mentioned anywhere before decorator is defined?

@rtm

This comment has been minimized.

Copy link

commented Jan 14, 2016

Decorators are all about sugar; there's no new functionality AFAIK.
Proponents want to write

var o = {
  @log
  func(a, b) { return a+b; }
};

and have the function logified. They also want to compose decorators

var o = {
  @log
  @computed('a', 'b')
  func(a, b) { return a+b; }
};

None of those things are (easily) possible with functions returning
functions and other alternatives.

On Fri, Jan 15, 2016 at 12:33 AM, Kamil Tomšík <notifications@github.com>
wrote:

> Wouldn't it be possible to throw syntax error if function is mentioned
> anywhere before decorator is defined?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/wycats/javascript-decorators/issues/4#issuecomment-171740073>
> .
>
@cztomsik

This comment has been minimized.

Copy link

commented Jan 14, 2016

Yep, I am here because I'd love to write:

@log
export function xyz(){
  ...
}
@calebmer

This comment has been minimized.

Copy link

commented Jan 14, 2016

Why can we not just throw an error if the decorator isn't hoisted?

This proposal is built on top of ES6 therefore we can assume hoisted imports are available and in a single file a decorator of a hoisted function can be a hoisted function.

We don't need to add anything else to the language, we have the tools to make hoisted decorators work. Why not?

@lukescott

This comment has been minimized.

Copy link

commented Mar 9, 2016

What if you decorate a hoisted function lazily:

@exclaim
function sayHello(name) {
  console.log("Hello " + name);
}
function exclaim(func) {
  return function(name) {
    return func(name + "!");
  }
}

Desugars to:

function sayHello() {
  console.log("decorate late");
  sayHello = exclaim(function sayHello(name) {
    console.log("Hello " + name);
  });
  return sayHello.apply(this, arguments);
}

function exclaim(func) {
  return function(name) {
    return func(name + "!");
  }
}

sayHello("John");
sayHello("Bill");

Output:

decorate late
Hello John!
Hello Bill!

You would only do this if the function you are decorating has been hoisted. This should work regardless if the decorator is hoisted or not.

@RReverser

This comment has been minimized.

Copy link

commented Mar 10, 2016

This thread becomes repetition of same ideas that were already discussed, over and over. Maybe it would make more sense to lock the issue for now?

@lukescott

This comment has been minimized.

Copy link

commented Mar 10, 2016

@RReverser perhaps I'm missing something. Has the idea I expressed above been expressed earlier?

@lukescott

This comment has been minimized.

Copy link

commented Mar 10, 2016

Nevermind. While it works, the reference is different before and after the call.

@darsain

This comment has been minimized.

Copy link

commented Oct 9, 2016

What about decorating a return value? Would it be treated the same as export statements, however that gets resolved?

function foo() {
  @bar
  return function () { ... }
}

or

function foo() {
  return @bar function () { ... }
}

And of course I'm also here to throw my +1 for function decorators :)

@ackvf

This comment has been minimized.

Copy link

commented Mar 13, 2018

const and let behave slightly different. Cannot we have decorators for these?

@foo
const fun = () => {}
@ukari

This comment has been minimized.

Copy link

commented Mar 13, 2018

@ackvf
identifier claimed by const can't be reassign, so the snippet you give can't be translate into reassign-style

const fun = () => {}
fun = foo(fun)

instead of reassign-style, it could be translate into wrap-style

const fun = foo(() => {})

but reassgin-style has a benefit that help foo get identifier's name when it assign to a function, like this

let foo = fn => (console.log(fn.name), fn)
let fun = ()  => {}
fun = foo(fun)

I implement let decorator in babel, here is a example which needs the feature to get let function's name.

javascript-let-decorators

@Hypnosphi

This comment has been minimized.

Copy link

commented May 4, 2018

You might want to use pipeline operator for that instead:

const foo = x => x * x
  |> memoize
  |> debounce(100)
@stylemistake

This comment has been minimized.

Copy link

commented Jul 2, 2018

Why do we have a problem with removing hoisting altogether? Classes don't hoist, const/let declarations don't hoist as well. I suggest that at the moment user decorates a function, it becomes unhoisted, and it's his responsibility to properly position that function within the code, just like with classes.

For example this:

@decorate
function foo() { return 1; }
console.log(foo()); // 1

...gets transformed into this:

const foo = decorate(function foo() { return 1; });
console.log(foo()); // 1

And if user assumes that it's hoisted, throw a ReferenceError:

console.log(foo()); // 1 - OK
function foo() { return 1; }
console.log(foo()); // 1
console.log(foo()); // ReferenceError
@decorate
function foo() { return 1; }
console.log(foo());

I believe JS should softly guide people away from hoisting, and remove bad language features overall.

@mlanza

This comment has been minimized.

Copy link

commented Jul 5, 2018

It'd be a shame to exclude decorators from plain functions.

It was said that hoisting isn't going away, one can assume backwards compatibility. But what if something akin to "use strict" – e.g. "no hoisting" – could be added to the top of a script/module? It would be considered a compilation hint. You would only use it in situations like this where hoisting gets in the way.

@Macil

This comment has been minimized.

Copy link

commented Jul 5, 2018

My understanding is that the big reason a script-wide feature like strict mode actually made it through in the first place was not because it threw away old misfeatures, but because the act of throwing away those misfeatures enabled brand new valuable use cases (SES / Google Caja javascript sandboxing). And the separate modes idea finally went away in the new happy-path case: modules force strict mode on. I think the standards groups would be extremely hesitant to reverse that victory to re-add a new script/module-wide "use stricter" mode.

Instead of script/module-wide settings, I think it makes a lot of sense to look at how the async-await feature added a new "await" keyword. "await" was not a reserved word in Javascript prior to async-await being added, so if it were added as a new reserved word, then all code that used "await" as a variable name would break. The standard solved this by making "await" a keyword only inside of async functions. The standard avoided breaking old code by making you opt in to the new behavior by making a function async.

Making it so decorated functions don't hoist seems to me like a strategy consistent with how async-await was added without breaking old code. You locally opt in to the new behavior by using a new feature.

@tlrobinson

This comment has been minimized.

Copy link

commented Mar 7, 2019

I don't like being that +1 guy, but this is sorely missed. Assignment decorators (tc39/proposal-decorators#51) and disabling hoisting on decorated function declarations seem like very reasonable solutions.

@dimaqq

This comment has been minimized.

Copy link

commented May 30, 2019

Come from the fair land of Python, [plain / const x = () =>] function decorators are perhaps more important than class member function decorators.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.