Decorators for functions

[Andreas Rossberg]

On 22 October 2015 at 19:25, Jordan Harband <ljharb at gmail.com> wrote:
> Andreas, thanks for correcting me on the optimization angle. I've been under
> that impression for awhile.
>
> Are you saying that to achieve the optimization I envision, we'd need
> declarative syntax for descriptor properties (like enumerability etc),
> rather than function calls?

Yes, there would need to be a sufficient degree of phase separation,
such that these annotations can be reliably gathered and inspected at
compile time, and are known to be invariant at runtime.

/Andreas


> On Thu, Oct 22, 2015 at 9:20 AM, Jonathan Bond-Caron
> <jbondc at 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).
>>
>