<div dir="ltr">Well, I see, it's not worse than other dynamic typing issues (think about `invokeThat.call()` being called on undefined or null, the exception only gives you a runtime error and you could always wrap in a try-catch, see the message and translate to yoour own exception or recover) but that does not relate at all with decorators which is my point. I agree on `Reflection.isClass` although I should check the spec in the search for something related with that specific topic but returning to the previous discussion about which syntax to use when decorating functions, I don't see this is a blocker for extending present decorator syntax to functions.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 23, 2015 at 12:17 PM, Andrea Giammarchi <span dir="ltr"><<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">well <span class=""><div><br></div><div>> <span style="font-size:12.8px">Can you point me some example where not distinguishing between functions and classes would be fatal, please?</span></div><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">the fact a class throws once invoked like a function isn't enough fatal to you?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">```js</span></div><div><span style="font-size:12.8px">function invokeThat() {</span></div><div><span style="font-size:12.8px">  var result = Object.create(this.prototype);</span></div><div><span style="font-size:12.8px">  return this.apply(result, arguments) || result;</span></div><div><span style="font-size:12.8px">}</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">invokeThat.call(function sum(a, b) { return a + b; }, 1, 2); // 3</span></div><div><br></div><div><span style="font-size:12.8px">invokeThat.call(</span><span style="font-size:12.8px">class Point{constructor(x,y){this.x=x;this.y=y;}}</span><span style="font-size:12.8px">, 10,  15);</span><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">// </span><span style="font-size:12.8px">Uncaught TypeError: Class constructors cannot be invoked without 'new'(…)</span></div><div><span style="font-size:12.8px">```</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">We are missing a `Reflection.isClass` ... useful or not, we've got two kind of "invokables" and nobody can distinguish from them.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Regards</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 23, 2015 at 10:56 AM, Salvador de la Puente González <span dir="ltr"><<a href="mailto:salva@unoyunodiez.com" target="_blank">salva@unoyunodiez.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Andrea.<br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Oct 22, 2015 at 10:34 PM, Andrea Giammarchi <span dir="ltr"><<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">which one is true?<div><br></div><div>> <span style="font-size:12.8px">I think there is no ambiguity at all ... decorating a function should be like decorating a class</span></div><div><br></div><div>'cause I think those are very different things.</div></div></blockquote><div><br></div></span><div>As far as I know, classes in ES6, apart from preventing you from calling without `new` (and minor subclassing details), are identical to functions.<br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>You gonna wrap for sure the first one, you most likely ever even bother replacing the class, rather enriching its prototype or its public statics.</div></div></blockquote><div><br></div></span><div>Well, is not as sure you want to wrap a function at all. Suppose:<br><br>```<br></div><div>// operaations.js<br></div><div>@priority(2)<br></div><div>function taskA() { doSomething(); }<br><br></div><div>@priority(1)<br></div><div>function taskB() { doSomething(); }<br><br></div><div>@priority(5)<br></div><div>function taskC() { doSomething(); }<br><br></div><div>taskManager.register(taskA, taskB, taskC);<br></div><div>taskManager.run(); // run taking into account priority symbol of the functions<br></div><div><br></div><div>// taskManager.js<br>var priority = new Symbol();<br><br></div><div>function priority(p) {<br></div><div>  return function(target) { target[priority] = p; }<br></div><div>}<br></div><div>```<br></div><div><br></div><div>On the contrary, you would want to replace a class completely:<br><br>```<br></div><div>@singleton<br></div><div>class system {<br></div><div>  get version() { return '1.0.0'; }<br></div><div>  get drives() { return ...; }<br></div><div>}<br><br></div><div>console.log(system.version);<br></div><div><br></div><div>function singleton(target) {<br></div><div>  return target();<br></div><div>}<br></div><div>```<br></div><div><br></div><div>I'm not saying is not important to distinguish between classes and functions, I'm just saying, it is not as important and not critical for the decorator syntax. It suffices for a framework to make their classes to inherit from a custom base object with a symbol `isClass` set to true to allow their own decorators to distinguish between classes and functions but these are specific-implementation details. What is true is the the syntax works for regular functions and class based functions.<br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Maybe it's me overlooking at this, but the fact we cannot distinguish between classes and functions doesn't feel right to me.</div></div></blockquote><div><br></div></span><div>No, sorry, maybe it's me that I can not see a harmful side effect here. Can you point me some example where not distinguishing between functions and classes would be fatal, please? Maybe this way, I (and others) understand your concerns.<br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Regards</div><div><br></div><div>P.S. babel has some target (browsers mostly, and nodejs) but it shouldn't be the reason to choose a pattern instead of another, or at least not the only one</div></div></blockquote><div><br></div></span><div>Of course, but it is a clear indicator of semantics. It's very valuable for a language to allow its own declarative semantics to be expressed in a programmatic fashion as it denotes a very consistent and versatile data & execution models.<br></div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><br></div><div><br></div><div><br></div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 22, 2015 at 9:26 PM, Salvador de la Puente González <span dir="ltr"><<a href="mailto:salva@unoyunodiez.com" target="_blank">salva@unoyunodiez.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Hi people.<br><br>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:<br><a href="https://babeljs.io/repl/#?experimental=true&evaluate=true&loose=false&spec=false&code=%40decorator%0Aclass%20A%20%7B%7D" target="_blank">https://babeljs.io/repl/#?experimental=true&evaluate=true&loose=false&spec=false&code=%40decorator%0Aclass%20A%20{}</a><br><br></div><div>You'll see:<br><br>```<br>A = decorator(A) || A;<br>```<br><br></div><div>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:<br><br>```<br></div><div>function decorator(target, name='', descriptor=null) {<br></div><div>  if (descriptor) console.log('Decorating a member');<br></div><div>  else console.log('Decorating either a function or class');<br></div><div>}<br>```<br><br></div><div>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.<br><br></div><div>So, the generated code for:<br><br>```<br></div><div>@decorator<br></div><div>function A() { }<br>```<br><br></div><div>Should be:<br><br>```<br></div><div>function A() {}<br></div><div>A = decorator(A) || A;<br></div><div>```<br><br></div><div>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.<br><br></div><div><br></div><div>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.<br></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 22, 2015 at 9:52 PM, Andrea Giammarchi <span dir="ltr"><<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Ron, there's **no way** you can distinguish a class from  a generic function in current specifications.<div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>Regards</div><div><br></div><div><br></div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 22, 2015 at 7:32 PM, Ron Buckton <span dir="ltr"><<a href="mailto:Ron.Buckton@microsoft.com" target="_blank">Ron.Buckton@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Andrea,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">```js<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">function memoize(target, key, descriptor) {<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">  switch (Reflect.getDecoratorUsage(arguments)) {<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">    case "class":
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">      // `target` is the class constructor. `key` and `descriptor` are undefined.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">    case "function":<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">      // `target` is the function. `key` and `descriptor` are undefined.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">    case "method":<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">      // `target` is the object containing the method (e.g. constructor
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">      // for a static method, prototype for a prototype method, or
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">      // instance for an object literal method).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">      // `key` is the string or symbol property name for the method.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">      // `descriptor` is the property descriptor for the method.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">    case "accessor":<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">      // `target` is the object containing the accessor (e.g. constructor
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">      // for a static accessor, prototype for a prototype accessor, or
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">      // instance for an object literal accessor).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">      // `key` is the string or symbol property name for the accessor.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">      // `descriptor` is the property descriptor for the accessor.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">  }<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">}<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">```<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Ron<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif"> es-discuss [mailto:<a href="mailto:es-discuss-bounces@mozilla.org" target="_blank">es-discuss-bounces@mozilla.org</a>]
<b>On Behalf Of </b>Andrea Giammarchi<br>
<b>Sent:</b> Thursday, October 22, 2015 10:47 AM<br>
<b>To:</b> Yongxu Ren <<a href="mailto:renyongxu@gmail.com" target="_blank">renyongxu@gmail.com</a>><span><br>
<b>Cc:</b> es-discuss mailing list <<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a>><br>
<b>Subject:</b> Re: Decorators for functions<u></u><u></u></span></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">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)<u></u><u></u></p><div><div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Regards<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div><div><div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Thu, Oct 22, 2015 at 6:29 PM, Yongxu Ren <<a href="mailto:renyongxu@gmail.com" target="_blank">renyongxu@gmail.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border-style:none none none solid;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">I don't think <u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">><span style="font-size:9.5pt"> ```@@ or @() or @::meomize```</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">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.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">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):</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">1.  decorator that alter the code behavior,  the currently proposed decorator. Such as ```@memoize```</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">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?):</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">```</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">@deprecated@</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">@number,number=>string@/*type checking*/</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">@debug("this message will only print in development mode")@</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">```</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">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.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Thu, Oct 22, 2015 at 11:20 AM, Jonathan Bond-Caron <<a href="mailto:jbondc@gdesolutions.com" target="_blank">jbondc@gdesolutions.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border-style:none none none solid;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">On Thu Oct 22 07:44 AM, Andreas Rossberg wrote:<br>
> > determined at creation time, allowing for massive engine optimization,<br>
><br>
<br>
Ya I'm not sure from which hat "massive engine optimization" comes from?<br>
<br>
What's meant is likely using decorators as annotations (compile time optimizations hints):<br>
<a href="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" target="_blank">http://www.google.com/patents/US7013458</a><br>
<br>
Or 'ambient decorators':<br>
<a href="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" target="_blank">https://github.com/jonathandturner/brainstorming/blob/master/README.md#c6-ambient-decorators</a><br>
<br>
There's 2 patterns (maybe more?):<br>
(a) Tagging a 'tree transformation'  on a node.<br>
(b) Metadata at compile time on a node.<br>
<br>
The thing about (b) is it can easily live outside of the code (like in typescript where you have an optional header/declaration file)<br>
<br>
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).<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><br>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="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" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12pt"><br>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="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" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>

</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>