Parameter decorators

[okunokentaro]

Hi.

in TypeScript 1.5 Alpha.

// foo.ts
function Parent(...args: any[]) {
  console.log('Parent args', args);
  return (...args: any[]) => {
    console.log('cb args', args);
    return args[0];
  };
}

class Clazz {
  A: any;
  B: any;
  constructor(@Parent(123) A: any, @Parent(456) B: any) {
    this.A = A;
    this.B = B;
  }
}

var a = new Clazz('foo', 'bar');
console.log(a);

It's a result.

$node foo.js
Parent args [ 123 ]
cb args [ [Function: Clazz], undefined, 0 ]
Parent args [ 456 ]
cb args [ [Function: Clazz], undefined, 1 ]
{ A: 'foo', B: 'bar' }

Currently (5.1.10) Babel cannot parse @ in this position.

babel /Users/armorik83/Desktop/foo.es6 --optional es7.decorators
/Users/armorik83/.nodebrew/iojs/v1.6.2/lib/node_modules/babel/node_modules/babel-core/lib/babel/helpers/parse.js:70
    throw err;
          ^
SyntaxError: /Users/armorik83/Desktop/foo.es6: Unexpected token (12:14)
  10 |   A: any;
  11 |   B: any;
> 12 |   constructor(@Parent(123) A: any, @Parent(456) B: any) {
     |               ^
  13 |     this.A = A;
  14 |     this.B = B;
  15 |   }

thanks.

[shuhei]

One thing to note here is that decorating function formal parameters is currently not part of the ES7 proposal. You can check out the proposals here.

[sebmck]

This isn't included in the ES7 proposal and TypeScript have added it by themselves. I think this is extremely dangerous and they're going to fuck over their users as the spec is in extreme flux and semantics are changing. Adding an unspecced and highly controversial decorator extension is going to cause pain.

[okunokentaro]

well, I agree.

[IgorMinar]

This feature is part of the ES proposal, as presented and discussed during May's TC39 meeting. See: https://esdiscuss.org/notes/2015-05-28

Can we get this issue reopened please?

[mgcrea]

Does it mean that #2138 would be acceptable as a stage 0 feature?

[jamiebuilds]

What's mentioned in https://esdiscuss.org/notes/2015-05-28 isn't really a proposal. I'm still hoping there will be something formal written up. Until that happens it's not going to end up on https://github.com/tc39/ecma262/blob/master/stage0.md.

cc @IgorMinar @bradlygreen @mhevery

[gionkunz]

There doesn't seem to be an agreement on this at all if I look at the meeting protocol specially when it comes to the scope and dynamic nature of function parameters. There are no decorators for functions because of the hoisting issues. Currently frameworks work around this by using property decorators and effectively treat them as class method decorators (which when writing them also seems right), but effectively they are just property decorators. As long as there are no real function decorators, there won't be any function parameter decorators.

Constructors can't have decorators in the ES7 decorator proposal as they don't get defined as object properties and classes can only have decorators because the resulting constructor function is not hoisted. This is already confusing but after reading all those threads, the limitations seem to be quite hard and all pointing back to the hoisting issues.

Let's say, just hypothetically, that TC39 agrees on the "workaround" of treating all functions with decorators on them as function expressions and don't hoist them. Then there would possibly be a solution where function and function parameter decorators could exist. However, there will be a conflict with property descriptors I guess, because how would JavaScript know if you're defining a function decorator or a property decorator when a function is defined inside a class? Maybe the short hand class { @A() a() {} } could assume function level decorators and class { @A() a: function() {} } would assume class property level? Still not very clean I guess.

I wonder how TypeScript implemented this? I'm still trying to keep things pure ECMAScript but having function and function parameter decorators is just really nice for framework API design and tooling support. I really hope that there's a super brain somewhere who finds a good solution for this issue.

[jamiebuilds]

I spoke to @jonathandturner about this. According to him, the tc39 decided decorators are going to be in two chunks. Chunk 1 is classes, class members, and maybe class properties. Chunk 2 is parameter decorators, maybe function decorators, etc. which likely needs more work in the reflection system.

I say it's too early to be talking about this. I also haven't heard much interest outside of the Angular team so I'm bearish on this ever being part of the standard.

Closing as wontfix for now. Contribs feel free to reopen.

[babel-bot]

Comment originally made by @IgorMinar on 2016-02-02T17:35:41.000Z

Param decorators proposal has been accepted by TC39 a few days ago and are at stage 0 now: tc39/ecma262#323

---

Comment originally made by @shuhei on 2016-02-19T15:52:18.000Z

[[ https://docs.google.com/document/d/1Qpkqf_8NzAwfD8LdnqPjXAQ2wwh8BBUGynhn-ZlCWT0/edit | The stage 0 proposal]] doesn't specify how parameter decorators should work but it shows the syntax.

Is it acceptable to add only parser support first and implement appropriate transform when the proposal becomes implementable? If only babylon parses the syntax, people can start building transform plugins, like Angular 2 annotation, on top of it.

---

Comment originally made by @IgorMinar on 2016-02-20T00:52:14.000Z

@shuhei the actual transform is still being debated. TypeScript implements one, but I expect that it will still change. Ron Buckton from MS has a Mirrors proposal which seems like the best way forward for this as well as several other decorator related transforms so we will most likely end up heading in that direction.

In the meantime I think that implementing the parser support and making it possible to implement the actual transform via a plugin like yours https://github.com/shuhei/babel-plugin-angular2-annotations would be the most preferable solution.

We want the babel users to be able to use this syntax with Angular apps while shielding them from the underlying implementation that we'll tweak as spec matures.

[hzoo]

@babel-bot move to babel/proposals

[babel-bot]

Hey @armorik83! I've moved your issue to the correct repository. Please make sure to keep an eye on the new issue for the latest information.