Or just use call constructor:
class F {
#decorator
call constructor() {
...
}
}
Rick
On Tue, Oct 20, 2015 at 9:19 AM Matthew Robb <matthewwr...@gmail.com> wrote:
> Why not just do:
>
> ```
> const {myFunc} = {
> @someDecorator;
> myFunc() {
>
> }
> };
> ```
>
>
> - Matthew Robb
>
> On Tue, Oct 20, 2015 at 9:00 AM, Andrea Giammarchi <
> andrea.giammar...@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 <r...@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.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
>>
>>
> _______________________________________________
> 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
