I agree with Andrea, basically nothing after es3 is a "must have", if we
apply the same argument.
I see a lot possibilities of decorator, I think it would be great if it can
be used on any lvalue, or even statements.
some of the application I can think of:
```
//static type checking
@type(number,number,number)
function f(a,b){
....
}
@debug(unitTestForFunction)
let f = (x) => .....
@parallel
for(.......){.......}
```
I think the best part of decorator is it can be processed by compiler or
polyfilled, so we can use them to instruct translator such as babel, to do
extra checking during development and drop them in production. It can also
be used by JET, if supported. Extra type checking, debugging can be ignored
by native engine, polyfilled to function that does nothing(as fallback if
no native support), or optimized as static typed function for performance.
I'd love to see a limitless decorator that also allows browser/compiler to
receive hints from developers.
On Wed, Oct 21, 2015 at 7:12 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> I agree it's not a "must have", considering what we lose if applied
> (portability) + you are back to broken portability with @meomize function
> ... VS meomize(function)
>
> So, I think portability is more important than some edge case without
> parenthesis around and if really wanted as a pattern,there is a workaround.
>
> Create an object to unpack it ... why not ... named functions? why not ...
> I'm used to write `{method: function method() {}}` for debugging sake and
> I like named functions but going even more dirty with the workaround maybe
> an array to unpack would make it less maintainable but less verbose too.
>
> It will still be portable, which is all it matters to me.
>
> Regards
>
>
>
>
>
> On Wed, Oct 21, 2015 at 1:01 PM, Alexander Jones <a...@weej.com> wrote:
>
>> Although this works, it seems like a bit of a violation of
>> say-what-you-mean and dont-repeat-yourself to me. You have to write the
>> name of each function twice, and you are defining a shorthand object
>> literal just for the sake of unpacking it.
>>
>> If we must have syntax for this, I'd propose hijacking @ to mean general
>> paren-free invocation, using the same precedence rules as Coffee:
>>
>> ```js
>> const fibonacci = memoize(function(n) {...});
>> const fibonacci = @memoize function(n) {...};
>> const fib100 = @fibonacci 100;
>> @window.alert "If this syntax works for functions, why not let it work
>> for anything?";
>> ```
>>
>> But I must ask - why *exactly* do people have a problem with the extra
>> brackets again? Is it really just because we don't have good paredit or
>> other tree-based editing for JS yet? (Or do we?)
>>
>> On Wednesday, 21 October 2015, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> Again, everything can be defined in a similar way, actually granting
>>> those function cannot posibly be declared or redefined differently, being
>>> constants.
>>>
>>> ```js
>>>
>>> const {
>>> assert,
>>> log,
>>> add
>>> } = {
>>> @conditional(DEBUG)
>>> assert(condition, message = "assertion failed.") {
>>> if (!condition) throw new Error(message);
>>> }
>>>
>>> @conditional(TRACE)
>>> log(message) {
>>> return target => function () {
>>> console.log(message);
>>> return target.apply(this, arguments);
>>> };
>>> }
>>>
>>> @metadata("design:paramtypes", () => [Number, Number])
>>> @metadata("design:returntype", () => Number)
>>> function add(a, b) {
>>> return a + b;
>>> }
>>>
>>> };
>>> ```
>>>
>>> Beside that, that gist is completely unreadable to my eyes, I guess it
>>> would take some time to be maintained as well if that was production code.
>>>
>>> The work around fixes all that, it keeps portability of the current
>>> proposal, and it ensure log will always be that log and nothing else in
>>> that very same scope + strawberry on top, less writing and always named
>>> functions.
>>>
>>> How cool is that?
>>>
>>> Best Regards
>>>
>>>
>>>
>>>
>>> On Tue, Oct 20, 2015 at 8:26 PM, Ron Buckton <ron.buck...@microsoft.com>
>>> wrote:
>>>
>>>> I can think of numerous examples of how decorators could apply to
>>>> functions, and I’ve added them to a gist
>>>> <https://gist.github.com/rbuckton/37e944f7986e6833949e> [1] for easier
>>>> consumption. It’s true that simple decorators for functions can work as
>>>> simply as function calls, but this becomes a bit unwieldy if you need to
>>>> compose multiple decorators on a single function.
>>>>
>>>>
>>>>
>>>> Consider a scenario combining decorators providing runtime type
>>>> information as an annotation with one that adds runtime type checking. With
>>>> decorators this might be:
>>>>
>>>>
>>>>
>>>> ```js
>>>>
>>>> @paramtypes(() => [Number, Number])
>>>>
>>>> @returntype(() => Number)
>>>>
>>>> @checked
>>>>
>>>> function add(x, y) { return x + y }
>>>>
>>>> ```
>>>>
>>>>
>>>>
>>>> If I just use function expressions, this is feasible if a bit awkward:
>>>>
>>>>
>>>>
>>>> ```js
>>>>
>>>> const add =
>>>>
>>>> paramtypes(() => [Number, Number])(
>>>>
>>>> returntype(() => Number)(
>>>>
>>>> checked(
>>>>
>>>> function (x, y) { return x + y; })))
>>>>
>>>> ```
>>>>
>>>>
>>>>
>>>> It feels a bit developer-hostile to have to rebalance parentheses if
>>>> you want to add a decorator, and there are ASI hazards if you misplace an
>>>> opening paren. Also, you can no longer infer the function name “add” from
>>>> the const binding.
>>>>
>>>>
>>>>
>>>> Using `::` isn’t a great replacement either, as there are many hazards
>>>> such as:
>>>>
>>>>
>>>>
>>>> ```js
>>>>
>>>> // The following means “call `decorator` with `this` bound to the
>>>> function object”.
>>>>
>>>> // Also, it becomes impossible to infer the function name “a” from the
>>>> let binding.
>>>>
>>>> let a = function() { }::decorator(x)
>>>>
>>>>
>>>>
>>>> let b = function() { }
>>>>
>>>> ::some.decorator(x) // ASI hazard as `::` can be either prefix or infix.
>>>>
>>>> ```
>>>>
>>>>
>>>>
>>>> One of the initial drivers for decorators was class methods, as there’s
>>>> no expression context immediately inside the class body in which you can
>>>> use either of the above scenarios. This necessitated a declarative form for
>>>> decorators to allow these scenarios to exist. Having parity across class
>>>> methods, classes, and functions (of all kinds) presents a more consistent
>>>> story to developers. The upswing in decorator use in both TypeScript and
>>>> Babel has been very positive, with libraries like Angular leveraging
>>>> decorators heavily in their codebase. Since we introduced decorators into
>>>> TypeScript, we’ve had a fair bit of feedback requesting support for
>>>> function decorators.
>>>>
>>>>
>>>>
>>>> I do think function decorators should wait until the Class/Property
>>>> decorators proposal advances further along the standards track. Axel’s
>>>> initial concerns/questions around hoisting are valid and there isn’t a
>>>> clear consensus on the semantics for functions. That said, I’ve been mostly
>>>> in the camp of introducing TDZ for function declarations that have
>>>> decorators. Decorators are a new syntactic form and we have the opportunity
>>>> to communicate this caveat with the development community by the time the
>>>> feature lands. It seems easy enough to explain that:
>>>>
>>>>
>>>>
>>>> ```js
>>>>
>>>> @decorator
>>>>
>>>> function func() { }
>>>>
>>>> ```
>>>>
>>>>
>>>>
>>>> Is the equivalent of:
>>>>
>>>>
>>>>
>>>> ```js
>>>>
>>>> let func = @decorator function() { }
>>>>
>>>> ```
>>>>
>>>>
>>>>
>>>> Introducing TDZ allows to generally warn early as part of the static
>>>> semantics, so developers won’t fall into a well with respect to adding a
>>>> decorator to a function and not being able to quickly understand how that
>>>> change affects the behavior of their code.
>>>>
>>>>
>>>>
>>>> I’m not certain what the current plan of record is, but the best
>>>> approach may be:
>>>>
>>>>
>>>>
>>>> 1. Advance and get consensus on the Class/Property decorators
>>>> proposal
>>>>
>>>> 2. Draft a separate proposal for decorators on function
>>>> expressions, generator function expressions, and arrows
>>>>
>>>> 3. Draft a separate proposal for decorators on function
>>>> declarations
>>>>
>>>>
>>>>
>>>> Steps 1 and 2 above shouldn’t be significantly difficult and don’t
>>>> necessarily introduce any major new semantics outside of the decorators
>>>> themselves. Step 3 covers a thornier issue as it not only introduces the
>>>> new semantics of decorators but also introduces side-effects due to
>>>> hoisting.
>>>>
>>>>
>>>>
>>>> Ron
>>>>
>>>>
>>>>
>>>> [1] https://gist.github.com/rbuckton/37e944f7986e6833949e
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf
>>>> Of *Andrea Giammarchi
>>>> *Sent:* Tuesday, October 20, 2015 3:34 AM
>>>> *To:* Axel Rauschmayer <rausc...@icloud.com>
>>>> *Cc:* es-discuss mailing list <es-discuss@mozilla.org>
>>>> *Subject:* Re: Decorators for functions
>>>>
>>>>
>>>>
>>>> You haven't provided a single use-case example, like how are you going
>>>> to decorate a function or why.
>>>>
>>>>
>>>>
>>>> IMO if implemented it will be incompatible with non ES6 code unable to
>>>> distinguish between classes and functions unless fully transpiled, making
>>>> decorators less portable.
>>>>
>>>>
>>>>
>>>> One thing I like about current state is that you can use decorators
>>>> even in ES5 browsers [1]
>>>>
>>>>
>>>>
>>>> Just my 2 cents, Regards
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> [1] as shown in the second example of the universal mixin module
>>>> https://github.com/WebReflection/universal-mixin#universal-mixin-
>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fWebReflection%2funiversal-mixin%23universal-mixin-&data=01%7c01%7cron.buckton%40microsoft.com%7c50c27148ba3543c448f608d2d939f7c4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=T1q%2bKVVIyc%2bNxSyG9Ri%2bmNAMPqq3p6Ydofoe1WQrg5U%3d>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Oct 20, 2015 at 10:30 AM, Axel Rauschmayer <rausc...@icloud.com>
>>>> wrote:
>>>>
>>>> https://github.com/wycats/javascript-decorators/blob/master/README.md
>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fwycats%2fjavascript-decorators%2fblob%2fmaster%2fREADME.md&data=01%7c01%7cron.buckton%40microsoft.com%7c50c27148ba3543c448f608d2d939f7c4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2fTFCt8Rrkx6pTvFLkcl8xfV5EKny35QpLPVTmm0aV8%3d>
>>>>
>>>> The decorator proposal does not include decorators for functions,
>>>> because it isn’t clear how to make them work in the face of hoisting.
>>>>
>>>> However, it would be great to have them. I see two possible solutions:
>>>>
>>>> – A decorator on a function declaration prevents hoisting.
>>>>
>>>> – Enable decorators for function expressions, arrow functions and
>>>> generator function expressions.
>>>>
>>>> Does either one of those make sense?
>>>>
>>>> Axel
>>>>
>>>> --
>>>> Dr. Axel Rauschmayer
>>>> a...@rauschma.de
>>>> rauschma.de
>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2frauschma.de&data=01%7c01%7cron.buckton%40microsoft.com%7c50c27148ba3543c448f608d2d939f7c4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Vclw%2fyI29j4WqkHWjTgaZtoL12pnJNCWYBJK4wTYVA0%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%7c50c27148ba3543c448f608d2d939f7c4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7t2BTGHrR322y2keuKyyEhgwUSIOCCN3vzv9CbXzdn8%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
