Decorators for functions

[Matthew Robb]

Why not just do:

```
const {myFunc} = {
  @someDecorator;
  myFunc() {

  }
};
```


- Matthew Robb

On Tue, Oct 20, 2015 at 9:00 AM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> You completely misunderstood me Bob, I don't think there's any valid use
> case for functions at all, including methods and ... .**specially**
> methods!!!
>
> I was thinking about decorators for classes, when you enrich their
> prototype in case the decorator receives a function instead of an object,
> or you enrich the object in every other case.
>
> You transform at runtime prototype methods??? Good for you, but that's
> something I'd never do, unless we are talking about lazy evaluation on the
> instance, where I don't see how lazy evaluation for an inherited method has
> anything to do with *functions* decorators.
>
> The difference is huge, methods will most likely have a `this` reference
> to be promoted on eventually, in  the other case you have a function that
> unless its body has "switches" can cannot really promote much by itself and
> passing it around as higher order function that mutates? ... yak!
>
> As summary: does anyone has a valid use case for a generic function
> decorator? 'cause I still don't see one, and having decorators for any sort
> of function would be problematic in terms of code portability, which is all
> I am saying.
>
> Regards
>
>
>
>
>
>
>
>
>
>
> On Tue, Oct 20, 2015 at 1:40 PM, Bob Myers <rtm at gol.com> wrote:
>
>> So wait, you agree there are valid use cases for decorating functions
>> when they are methods on an object (although I don't see much along that
>> line in the proposal). But if the function is "stand-alone" suddenly the
>> use cases evaporate?
>>
>> For example, I hack on and off on a framework involving transforming
>> functions into self-updating versions of themselves. Of course I can write
>> this as
>>
>>     self_updatify(function a() { })
>>
>> but it would be more compact and readable to say
>>
>>     @self_updatify
>>     function a() { }
>>
>> Which is, please correct me if I'm wrong, all decorators are about. To
>> take one example, Ember wants to use decorators not to get new
>> functionality, but to make the writing of computed properties less ugly,
>> among other reasons. (The fact that Ember makes little use of non-method
>> functions may also be one reason for the low priority placed on figuring
>> out how to decorate functions.)
>>
>> We can work to develop more examples and motivations and use cases for
>> decorated functions, although frankly it seems a little odd, as I mentioned
>> above, that there could be compelling use cases for decorated methods but
>> not for decorated functions. For the purposes of this discussion I will
>> stipulate that having decorated functions is an idea worth pursuing. If you
>> disagree, there's not point in reading further (but you might want to stop
>> and ask yourself why if it's such a great idea to have decorated methods,
>> no-one will ever want decorated functions).
>>
>> The only problem as far as I am aware is how to handle hoisting.
>>
>> AFAICS, hoisting is not an issue if the decorator has no side effects. Of
>> course there is nothing wrong with writing decorators with side effects,
>> and there are valid use cases for doing so, but they are rare. Furthermore,
>> even if a decorator does have side-effects, in only some subset of such
>> cases will the side effects together with hoisting result in unexpected
>> behavior.
>>
>> So to say that we will simply give up on decorated functions because of
>> the few cases where decorators have side effects, and those side effects
>> cause unexpected behavior due to hoisting, is really throwing out the baby
>> with the bathwater. We are telling people that you cannot decorate
>> functions at all, ever, or to decorate functions they must wrap them in a
>> class or object, because of some potentially unexpected behavior in what is
>> decidedly an edge case.
>>
>> Various proposals have been made on this topic, including hoisting
>> separately from decorating, hoisting and decorating at the same time,
>> change hoisting behavior for decorated functions, etc. etc. Each of these
>> ideas has its proponents and those who think it is the work of the devil. I
>> will not go into the details of these approaches here, and to do so is
>> actually a bit above my pay grade.
>>
>> I would just say that it is odd in the extreme that a group of
>> world-leading language designers would just throw in the towel when
>> confronted with a pretty small roadbump, instead of figuring out ways to
>> solve it. The alternative, which is to implement decorators only for
>> methods and classes and leave out functions because we couldn't figure it
>> out, seems like a major admission of failure.
>>
>> Bob
>>
>>
>> On Tue, Oct 20, 2015 at 4:03 PM, Andrea Giammarchi <
>> andrea.giammarchi at gmail.com> wrote:
>>
>>> 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-
>>>
>>> On Tue, Oct 20, 2015 at 10:30 AM, Axel Rauschmayer <rauschma at icloud.com>
>>> wrote:
>>>
>>>> https://github.com/wycats/javascript-decorators/blob/master/README.md
>>>>
>>>> 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
>>>>
>>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151020/dc1d0fe6/attachment.html>