Re: Arrow function declaration

2015-10-20 Thread Федор Неживой
Link fix 2015-10-20 11:40 GMT+06:00 Федор Неживой : > I'm looking for a champion for > https://github.com/gyzerok/ecmascript-arrow-function-declaration > > -- > С уважением > Неживой Федор. > -- С уважением

Re: Decorators for functions

2015-10-20 Thread Andrea Giammarchi
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

Decorators for functions

2015-10-20 Thread Axel Rauschmayer
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

Re: Decorators for functions

2015-10-20 Thread Bob Myers
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

Re: Decorators for functions

2015-10-20 Thread Frankie Bagnardi
Decorators can be both used to wrap things and to annotate them. For example, here we're setting a flag with the `web.method` function which is used by by this fictional 'web' framework. The others are used as middleware that modify the function arguments at each step. ```js export default

Re: Decorators for functions

2015-10-20 Thread Eli Perelman
More drive-bys. I could see decorators as a nice way to define "functional" behavior for generic functions: @curried var add = (a, b) => a + b; @memoize var fetch = (url) => /* logic */; Eli Perelman On Tue, Oct 20, 2015 at 8:42 AM, Kevin Smith wrote: > I would just

Re: Decorators for functions

2015-10-20 Thread Bob Myers
> You completely misunderstood me Bob. Sorry about that. > 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. Am I understanding this right that you are

Re: Decorators for functions

2015-10-20 Thread Andrea Giammarchi
Bob > Am I understanding this right that you are thinking of decorators as a type of trait mechanism? absolutely, which is what I've linked at the beginning ( universal-mixin module that already works with "ES7" proposed decorator syntax down to ES3 ) Your last example ```js @computed('dep1',

Re: Decorators for functions

2015-10-20 Thread Isiah Meadows
I would have to agree with Andrea here. I don't see any benefits decorated functions, e.g. `@memoize function inc(x) { return x + 1 }` would provide other than syntax over `const inc = memoize(x => x + 1)`. On Tue, Oct 20, 2015 at 11:00 AM, Andrea Giammarchi wrote:

RE: Decorators for functions

2015-10-20 Thread Jonathan Bond-Caron
On Tue Oct 20 05:30 AM, Axel Rauschmayer wrote: > The decorator proposal does not include decorators for functions, > because it isn’t > clear how to make them work in the face of hoisting. > What's the obsession with decorators? Decorators are like saying everyone can decorate their Christmas

Re: Decorators for functions

2015-10-20 Thread Alexander Jones
I've become convinced by this thread that we don't need this. Other languages where decorators are useful and prevalent don't have the expressivity JS has, particularly regarding dynamism and function expressions. JS `class` is an awkward case due to not supporting non-method members, but I think

Re: Decorators for functions

2015-10-20 Thread Andrea Giammarchi
If you don't pass the surrounding object / prototype I don't personally see any added value from using `fn.bind(null, Calculator)` or simply `dl.provide(Calculator, function add(calc, a, b) {})` Specially the export example would make my eyes bleed once the export is inside curly brackets: I've

Re: Decorators for functions

2015-10-20 Thread Matthew Robb
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,

Re: Decorators for functions

2015-10-20 Thread Andreas Rossberg
Drive-by-comment: On 20 October 2015 at 14:40, Bob Myers wrote: > AFAICS, hoisting is not an issue if the decorator has no side effects. Not so. Initialisation order is another issue. Consider: var x = 0 @bla(x) function f() {} Also, as a side note, pretty much *everything*

Re: Decorators for functions

2015-10-20 Thread Kevin Smith
> > 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. > Another drive-by... The trick is introducing new features without

Re: Decorators for functions

2015-10-20 Thread Andrea Giammarchi
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

Re: Decorators for functions

2015-10-20 Thread Andrea Giammarchi
FWIW that would make code portable, accordingly with current proposal, the object is received, the descriptor and its name are clear. I personally wouldn't mind that pattern, yet I'm curious about use cases for functions decorators. Regards On Tue, Oct 20, 2015 at 2:18 PM, Matthew Robb