ROUTE 66 - WORK IN PROGRESS

With babylon having problems parsing decorated generator functions it seems that the current specification of a decorator is too lax and by that overly complex.

While it is surely nice to have something like

@f?f:f1

it is way too much considering the common and thus standard use cases for decorators, which are

@decorate(options)
@decorate
class Foo {
...
}

and also considering that one is currently unable to

class Foo
{
    @decorate
    * gen() { yield 1; }
}

due to the fact that the current specification is based on LeftHandSideExpression, which for example causes the babylon parser to parse this as

BinaryExpression
    left: 'decorate'
    operator: '*'
    right: 'gen()'

How about limiting decorators to specialized variants of CallExpressionS and MemberExpressionS, which are presumably the most used forms of decorators. And, with that in place, the babylon parser could be fixed in order to support decoration of generator methods.

PROPOSAL

MemberReference _[Yield] :
  IdentifierName _[?Yield]
  MemberReference _[?Yield] [ Expression _{[In, ?Yield]} ]
  MemberReference _[?Yield] . IdentifierName _[?Yield]

DecoratorCallExpression _[Yield] :
  MemberReference _[?Yield] Arguments _[?Yield]
  DecoratorCallExpression _[?Yield] Arguments _[?Yield]
  DecoratorCallExpression _[?Yield] . IdentifierName _[?Yield]
  DecoratorCallExpression _[?Yield] [ Expression _{[In, ?Yield] ]}

Decorator _[Yield] :
  @DecoratorExpression _[?Yield]

DecoratorExpression _[Yield] :
  DecoratorCallExpression _[?Yield]
  MemberReference _[?Yield]

The above will allow us to

@decorators[Symbol](options)
@decorator(options)
@lib.decorator
class Foo
{
    // not sure about this one, production rule wise that is, though
    @broker.getInstance(IFancyDecorators).decorate()
    * gen() {}
}

and so on.

RATIONALE

The current specification of LeftHandSideExpression is way too lax and will prevent users from decorating generator methods, see the referenced babylon issue above.

With Angular2 using TypeScript, the available docs do present use of above depicted two use cases only. And even in Python and frameworks thereof, you will never see anything more complex than the above two use cases. The same with annotations in Java or similar such languages, where these two use cases have been made a fixed idiom of the language, which is actually true for Python, also.

@lukescott, @wycats, @loganfsmyth, @jayphelps, @Download You have already discussed this in #23 and I think that we should discuss this further.