Ron, there's **no way** you can distinguish a class from a generic function in current specifications.
Having one argument won't tell me much, having a way to know that is not a class I need to decorate (traits/mixins) but just a function, so ignoring its prototype and do something else, would be cool but it's unfortunately not possible or portable. How would you distinguish between a class or a function for a generic decorator? Or all you are saying is that decorators shouldn't be able to distinguish at all between a class, rather than a function? Regards On Thu, Oct 22, 2015 at 7:32 PM, Ron Buckton <ron.buck...@microsoft.com> wrote: > 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> 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> 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 > 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 > <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