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.giammar...@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 <rausc...@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
