Decorators for functions

Thu Oct 22 18:32:46 UTC 2015

Andrea,

Is your concern about disambiguating the usage of a decorator at the call site or within the body of the decorator? In the current proposal, you can decorate a class member, or the class itself.

When decorating a class member, three arguments are passed to the decorator: The target, the property key (string or symbol), and the descriptor. When decorating the class, one argument is passed to the decorator: The constructor function. Generally this means that you can disambiguate the usage of the decorator based simply on `arguments.length`, or testing for `undefined` for the property key or descriptor.

Would it be better to have a more consistent way to disambiguate the usage of a decorator from within the decorator? This could be addressed with something like a Reflect.getDecoratorUsage API or a `function.decoration` meta-property or the like. Consider something like:

```js
function memoize(target, key, descriptor) {
  switch (Reflect.getDecoratorUsage(arguments)) {
    case "class":
      // `target` is the class constructor. `key` and `descriptor` are undefined.

    case "function":
      // `target` is the function. `key` and `descriptor` are undefined.

    case "method":
      // `target` is the object containing the method (e.g. constructor
      // for a static method, prototype for a prototype method, or
      // instance for an object literal method).
      // `key` is the string or symbol property name for the method.
      // `descriptor` is the property descriptor for the method.

    case "accessor":
      // `target` is the object containing the accessor (e.g. constructor
      // for a static accessor, prototype for a prototype accessor, or
      // instance for an object literal accessor).
      // `key` is the string or symbol property name for the accessor.
      // `descriptor` is the property descriptor for the accessor.
  }
}
```

Ron

From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Andrea Giammarchi
Sent: Thursday, October 22, 2015 10:47 AM
To: Yongxu Ren <renyongxu at gmail.com>
Cc: es-discuss mailing list <es-discuss at mozilla.org>
Subject: Re: Decorators for functions

Removing ambiguity is my point since the very first post: current proposal is about a target, a property name, and a descriptor for such property ... having functions/variables decorators have no target (in strict mode undefined can't be a target, right?) and not necessarily a descriptor, or if any, always a data one with fields that makes no  sense (like enumerable within a private scope ... what does that even mean)

I'm all in for a distinct, separate, syntax to decorate "callables" or other variables as long as the current proposal will make for ES7 and won't be bothered by this different requirement.

Regards

On Thu, Oct 22, 2015 at 6:29 PM, Yongxu Ren <renyongxu at gmail.com<mailto:renyongxu at gmail.com>> wrote:
I don't think

> ```@@ or @() or @::meomize```

would really help much, you can tell what the decorator does by simply looking at its name. And looks like you can not use @ and @@ for the same decorator function without adding extra condition checking inside the function.

There are two patterns that we have discussed here, they are actually quite distinct. I still think we should support decorator on variables, but maybe we should have 2 distinct syntax for the normal decorators and "ambient decorators"(from Jonathan's post):

1.  decorator that alter the code behavior,  the currently proposed decorator. Such as ```@memoize```

2. decorator that absolutely does not alter the code behavior, only used for optimization, checking or debugging. Instead of @, a distinct syntax will be much clearer ex.```@annotatition@``` (Maybe it should be called annotation instead?):
```
@deprecated@

@number,number=>string@/*type checking*/

@debug("this message will only print in development mode")@
```

it sounds like terrible idea to have a decorator in code that you can not figure out if it will alter the code behavior by looking at it. I do like to see all the new ideas been added into javascript, but it is also necessary to eliminate the ambiguity whenever possible.

On Thu, Oct 22, 2015 at 11:20 AM, Jonathan Bond-Caron <jbondc at gdesolutions.com<mailto:jbondc at gdesolutions.com>> wrote:
On Thu Oct 22 07:44 AM, Andreas Rossberg wrote:
> > determined at creation time, allowing for massive engine optimization,
>

Ya I'm not sure from which hat "massive engine optimization" comes from?

What's meant is likely using decorators as annotations (compile time optimizations hints):
http://www.google.com/patents/US7013458<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.google.com%2fpatents%2fUS7013458&data=01%7c01%7cron.buckton%40microsoft.com%7c4f28552d1837468197db08d2db08dcea%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=atTz2em0YIlXUvUVgiWsZ5xKNjJsIOzm3wLejdDl33E%3d>

Or 'ambient decorators':
https://github.com/jonathandturner/brainstorming/blob/master/README.md#c6-ambient-decorators<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fjonathandturner%2fbrainstorming%2fblob%2fmaster%2fREADME.md%23c6-ambient-decorators&data=01%7c01%7cron.buckton%40microsoft.com%7c4f28552d1837468197db08d2db08dcea%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1aXPAnWuPpVgE3wCYZqcEnTaksCKqzwuq0bGLkkG8Uo%3d>

There's 2 patterns (maybe more?):
(a) Tagging a 'tree transformation'  on a node.
(b) Metadata at compile time on a node.

The thing about (b) is it can easily live outside of the code (like in typescript where you have an optional header/declaration file)

With (a), it seems more conservative to see how it gets used with classes before bolting on to functions (opinion: end result in java is not something to be proud of).

_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmail.mozilla.org%2flistinfo%2fes-discuss&data=01%7c01%7cron.buckton%40microsoft.com%7c4f28552d1837468197db08d2db08dcea%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=YHeobU0gimD8xIX0FwR3GAdjKwWiwOGNGUWVi%2bHZARg%3d>

_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmail.mozilla.org%2flistinfo%2fes-discuss&data=01%7c01%7cron.buckton%40microsoft.com%7c4f28552d1837468197db08d2db08dcea%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=YHeobU0gimD8xIX0FwR3GAdjKwWiwOGNGUWVi%2bHZARg%3d>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151022/48815037/attachment-0001.html>