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
