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
>>
>> Or 'ambient decorators':
>>
>> https://github.com/jonathandturner/brainstorming/blob/master/README.md#c6-ambient-decorators
>>
>> 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
>>
>
>
> _______________________________________________
> 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
