Hi people.
After reading the conversation, I think there is no ambiguity at all or,
may be, it must be there: decorating a function should be like decorating a
class, you can not distinguish between them and that's all. Just look at
the code generated in Babel:
https://babeljs.io/repl/#?experimental=true&evaluate=true&loose=false&spec=false&code=%40decorator%0Aclass%20A%20{}
You'll see:
```
A = decorator(A) || A;
```
And this is the traditional notion of decorator we see in Python and other
languages. A simple way to check for a generic decorator would be:
```
function decorator(target, name='', descriptor=null) {
if (descriptor) console.log('Decorating a member');
else console.log('Decorating either a function or class');
}
```
And it's very consistent if you think the only difference a ES6 class
introduces is that you are not allowed to call the class as a function.
So, the generated code for:
```
@decorator
function A() { }
```
Should be:
```
function A() {}
A = decorator(A) || A;
```
And that's all, if you always add the overwrite after the definition,
hoisting is irrelevant but if it worries you, simply avoid hoisting when
decorating as Axel suggested.
PS: Well thought, it must be possible for an hypothetical reflection
function to determine if a function is a class or not as classes are marked
to throw when they are not invoked with new.
On Thu, Oct 22, 2015 at 9:52 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> 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
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
