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-boun...@mozilla.org] On Behalf Of Andrea
Giammarchi
Sent: Thursday, October 22, 2015 10:47 AM
To: Yongxu Ren <renyon...@gmail.com>
Cc: es-discuss mailing list <es-discuss@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
<renyon...@gmail.com<mailto:renyon...@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
<jbo...@gdesolutions.com<mailto:jbo...@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@mozilla.org<mailto:es-discuss@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@mozilla.org<mailto:es-discuss@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
