CS2 Discussion: Features: decorators

[coffeescriptbot]

From @rattrayalex on July 23, 2016 2:51

Decorators are an increasingly popular feature of ES6, particularly with React development.

However, they use @atSyntax, which clashes with coffeescript's this. shorthand.

We could:

1. Come up with an alternative syntax for decorators
2. Come up with a new syntax for this. shorthand
3. Keep both as they are and just work hard to parse them
4. Get rid of this. shorthand
5. Don't add decorators
6. Any other ideas?

Thoughts?

Copied from original issue: coffeescript6/discuss#9

[coffeescriptbot]

From @carlmathisen on July 24, 2016 21:27

It is unfortunate that ES6 generator uses @ as well, but we should try to keep as much BC as possible - especially when it comes to basic stuff like this shorthand that literally everyone uses.

You're probably right, it's hard to parse and distinguish between the two if decorators were to keep the same symbol.

class A
  @decorator
  func: ->

Granted, when transpiled today it doesn't make sense - @decorator just becomes A.decorator;, but it is still valid JS. Who knows, it might even trigger a getter function in someone's app. Framer JS, for instance, heavily uses function getters for their properties with Object.defineProperty. https://github.com/koenbok/Framer/blob/master/framer/BaseClass.coffee#L20

So your first list item, come up with an alternative syntax for decorators, is probably the best solution. Maybe use * since it's an addition of information and functionality, but not sure if mixing in an operator is a good idea.

[coffeescriptbot]

From @rattrayalex on July 25, 2016 0:7

Sorry, BC?

EDIT: ah, Backwards Compatible. Yes, I'm increasingly coming around to that.

[coffeescriptbot]

From @rattrayalex on July 25, 2016 1:3

Let's brainstorm other ideas...

class A
  @decorator
  func: ->
class A
  %decorator  # maybe?
  func: ->
class A
  ^decorator  # I don't think so
  func: ->
class A
  &decorator  # actually, not bad – I like that it implies you're adding something
  func: ->
class A
  *decorator  # perhaps too similar to generator syntax? But I don't think actually problematic.
  func: ->

Any other ideas?

[coffeescriptbot]

From @carlmathisen on July 25, 2016 6:26

Regarding *, it's good point that it might be confused as a generator.

Btw, CoffeeScript's official docs on generator functions:

CoffeeScript functions also support ES6 generator functions through the yield keyword. There's no function*(){} nonsense — a generator in CoffeeScript is simply a function that yields.

[coffeescriptbot]

From @JimPanic on July 25, 2016 7:29

@carlmathisen That's a good point re yield! It might be a good idea to keep this as-is for now and make sure the current syntax works with ES6 generators.

Edit: whoops, this is the thread about decorators. Sorry. :)

[coffeescriptbot]

From @JimPanic on July 25, 2016 7:46

I've just looked at decorators in Python, Elixir and ES6. They all use @decorate syntax. Lua doesn't seem to have a special decorator syntax as far as I understood it (http://lua-users.org/wiki/DecoratorsAndDocstrings).

In the long run, it might be a good idea to find a different shorthand for this. and deprecate its current incarnation in favour of a "standard" decorator syntax embraced in quite a few languages and tools. The current CS syntax is heavily inspired by Ruby in this regard, which (as far as I can tell) doesn't sport syntax-backed decorators at all and has a vastly different stance on classes, modules and methods than JS does.

[coffeescriptbot]

From @carlmathisen on July 25, 2016 18:30

Although I understand the wish for a "standard" decorator syntax, I disagree with deprecation of @ shorthand for this. Decorators are merely a nifty feature, and shouldn't take a driver's seat on how a language is designed. The @ for this isn't just a random symbol either, it has a semantic meaning to it and it is very easy to automatically understand what it means.

If we decide to reserve a word or symbol for decorators, it could just as well be decorate. This might break some apps having a variable named decorate, but it's better than breaking 100% of CS code with @.

Example:

class A
  decorate readonly, deprecated
  func: ->

Btw, here is a discussion on decorators over at CoffeeScript's own issue tracker: #76. Interesting read, even though the issue is quite old.

[coffeescriptbot]

From @JimPanic on July 25, 2016 19:32

Decorators are merely a nifty feature, and shouldn't take a driver's seat on how a language is designed. The @ for this isn't just a random symbol either, it has a semantic meaning to it and it is very easy to automatically understand what it means.

You're probably right. 👍

Thinking about your proposal and how decorators seem to be implemented (and without having read #76), are we not be able to use decorators right now, without the keyword?

readonly = (fn) -> ((...) -> ...)

decorated_fn = readonly (foo) -> foo

I used this type of function "decoration" before. So introducing a keyword like decorate for language supported decorators is certainly a better option than what I proposed.

[coffeescriptbot]

From @carlmathisen on July 25, 2016 20:6

Your suggestion is basically what Jeremy says in #76 (tldr: no need for language support, just create a wrapper function)

[coffeescriptbot]

From @JimPanic on July 25, 2016 20:50

On 25 Jul 2016, at 22:06, Carl Mathisen notifications@github.com wrote:

Your suggestion is basically what Jeremy says in #76 (tldr: no need for language support, just create a wrapper function)

Ah, cool. But there might be implications that this doesn't cover. I don't know how far language support is adding additional features in ES201*. I'm pretty sure any distinction for decorators is a good thing to be able to create proper tools to use this feature.

[coffeescriptbot]

From @dadleyy on July 28, 2016 15:50

I know coffeescript today is against adding them but regarding getters and setters -- would decorators be used for this? If not, is it worthwhile opening a new issue and having the discussion there or is it assumed that they won't make it into this new project? Personally I really enjoy using getters in browser-side UI code. I have found it helpful to keep track of arbitrary business logic rules (a user can do this, can't do this, etc...) by writing a flags getter on some of my component delegates/services/controllers:

class DietManager {
  get flags() {
    let {meals} = this;
    let total_calories = 0;
    for(let i = 0, meal_count = meals.length; i < meal_count; i++) {
      total_calories += meals[i].calories;
    }
    return {total_calories};
  }
}

At least, I think the above is a good example of a use for getters.

[coffeescriptbot]

From @rattrayalex on July 28, 2016 17:15

@dadleyy

is it worthwhile opening a new issue and having the discussion there

Yes, please do! getters/setters would likely be an appropriate issue title.

[coffeescriptbot]

From @carlsmith on July 28, 2016 18:0

-1 on this. CoffeeScript already has decorators. ES3 already has them too. Every language with first-class functions supports decorators. What ES6 is adding is just syntactic sugar for passing a function to a decorator. CoffeeScript already has syntactic sugar for doing this, and it literally couldn't be improved on. You just put any expression (typically a name) that evaluates to a decorator in front of the function expression you want to decorate. If you have a decorator named memo, you can just put memo in front of anything you want to decorate.

# regular square function
square = (x) -> x * x
# memo decorated square function
square = memo (x) -> x * x

We don't need ES6 sugar in CoffeeScript. That's the whole point of CoffeeScript.

Decorators are an awesome feature, but every language already has them. It's just that some languages make applying them awkward. Python without special syntax:

def square(x): return x * x
square = memo(square)

Python with special syntax:

@memo
def square(x): return x * x

There's absolutely no need for special syntax in CoffeeScript. If we had to use parens for invocations, it'd be different:

square = memo((x) -> x * x)

From experience, I can say confidently that you never need those parens in practice. You can always use the name of a decorator as if it's a prefix operator.

Things are less pretty if you use functions that return decorators, but it still works well enough. You just wrap the decorator expression in parens:

square = (memo 10) (x) -> x * x

That could be a little bit prettier with special syntax, for example:

@memo 10
square = (x) -> x * x

But, it's a pretty big change to add minor convenience to a rare construct, and the new syntax would be awful when using functions as args:

employees.forEach(
    @memo 10
    (each) -> console.log each
)

That's a mess, especially when we already have:

employees.forEach (memo 10) (each) -> console.log each

Decorators never nest any deeper than that. You always either use a decorator, or call a function that returns a decorator (so you can parameterise the decorator). They are the only two forms decoration takes.

[coffeescriptbot]

From @rattrayalex on July 28, 2016 21:30

@carlsmith have you used es6 decorators? The examples you provide are not valid (they can't be user on top level functions).

How can one decorate a class in coffeescript with equivalent elegance to es6?