Re: Decorators for functions

[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 that is one of the actual problems that should
be solved.

Another major point I have is that most of the reasoning for decorator
syntax is actually generic reasoning for paren-free function invocation
à la Perl, Ruby, CoffeeScript, etc. Let's talk about that, instead of
building unilateral syntax extensions into the language.

On Tuesday, 20 October 2015, Jonathan Bond-Caron 
wrote:

> 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 trees.
> That's nice once a year but not when you start looking at all the
> different Christmas trees and have to maintain that stuff.
>
> Suddenly the single language you thought you understood has many dialects
> & philosophies.
> Aren't embeddable languages more interesting to learn then decorated trees?
>
> ___
> 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

RE: Decorators for functions

[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 trees.
That's nice once a year but not when you start looking at all the different 
Christmas trees and have to maintain that stuff.

Suddenly the single language you thought you understood has many dialects & 
philosophies.
Aren't embeddable languages more interesting to learn then decorated trees?

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Decorators for functions

[Ron Buckton]

I can think of numerous examples of how decorators could apply to functions, 
and I’ve added them to a 
gist [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 
Cc: es-discuss mailing list 
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-

On Tue, Oct 20, 2015 at 10:30 AM, Axel Rauschmayer 
mailto

Re: Decorators for functions

[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', 'dep2')
foo(dep1, dep2) { return dep1 + dep2; }
```

it's about prototype/object method decoration, which is OK as use case
'cause it sends the object/prototype as a target, the name 'foot' and the
descriptor with the function as its value.

I'm absolutely fine with that because it's contextual. If you have **only**
the function without a target though ... no that is the problem I am
 talking about, and it's purely related to portability of the proposal
itself:  right now is just sugar with a context (class/object), if we have
to consider functions as functions,  not as method and not as constructors
(ES5/3) then we have a portability problem and  it would  be a  pity
because decorators are a wonderful migration pattern, as they are proposed
now.

Add functions and goodbye portability in non transpiled code.

Hope it's clear what is my (actually) only concern in introducing extra
specifications for functions only: few benefits, possibly more code to
write, broken backward portability for pure /clean  environments that don't
want/have/use transpilers (nodejs, micro controlelrs, espruino, Yun etc)

Best Regards






On Tue, Oct 20, 2015 at 5:24 PM, Bob Myers  wrote:

> > 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 thinking of decorators as a
> type of trait mechanism?
>
> As I understand it, decorators are pure sugar. I like sugar as much as the
> next guy, as long as it addresses common use cases, helps us write more
> readable, maintainable code, and doesn't eat too much into future syntax
> space. But I am on the fence about decorators.
>
> It's worth noting that some kinds of decorators could possibly be handled
> via `::` syntax:
>
> (function() { })::decorate_me()
>
> However, it is worthwhile considering the Ember "computed property" use
> case. For those who don't know Ember, computed properties recompute
> themselves on demand when their dependencies change. This requires the
> dependencies to be declared somehow. Then, the dependencies need to be
> retrieved again within the function.
>
> The classic syntax for writing computed properties is:
>
> ```js
> foo: Ember.computed('dep1', 'dep2', function() { return this.get('dep1') +
> this.get('dep2'); })
> ```
>
> An alternative in widespread use is hardly prettier, and requires
> polluting the function prototype:
>
> ```js
> foo: function() { return this.get('dep1') + this.get('dep2');
> }.computed('dep1', 'dep2')
> ```
>
> The reason the Ember folks latched on to decorators is because they want
> to write this:
>
> ```js
> @computed('dep1', 'dep2')
> foo(dep1, dep2) { return dep1 + dep2; }
> ```
>
> and that is indeed much better. To accomplish this, the `computed`
> decorator would be roughly written as
>
> ```js
> function computed(...deps) {
>   return function(target, name, descriptor) {
> var undecorated = descriptor.value;
> descriptor.value = undecorated.apply(this, deps.map(dep =>
> this.get(dep));
> return descriptor;
>   };
> }
> ```
>
> The above is meant merely for illustrative purposes.
>
> The sweetness of the resulting sugar should attract a fair number of flies.
>
> --
> Bob
>
> On Tue, Oct 20, 2015 at 6:30 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Decorators for functions

[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 thinking of decorators as a type
of trait mechanism?

As I understand it, decorators are pure sugar. I like sugar as much as the
next guy, as long as it addresses common use cases, helps us write more
readable, maintainable code, and doesn't eat too much into future syntax
space. But I am on the fence about decorators.

It's worth noting that some kinds of decorators could possibly be handled
via `::` syntax:

(function() { })::decorate_me()

However, it is worthwhile considering the Ember "computed property" use
case. For those who don't know Ember, computed properties recompute
themselves on demand when their dependencies change. This requires the
dependencies to be declared somehow. Then, the dependencies need to be
retrieved again within the function.

The classic syntax for writing computed properties is:

```js
foo: Ember.computed('dep1', 'dep2', function() { return this.get('dep1') +
this.get('dep2'); })
```

An alternative in widespread use is hardly prettier, and requires polluting
the function prototype:

```js
foo: function() { return this.get('dep1') + this.get('dep2');
}.computed('dep1', 'dep2')
```

The reason the Ember folks latched on to decorators is because they want to
write this:

```js
@computed('dep1', 'dep2')
foo(dep1, dep2) { return dep1 + dep2; }
```

and that is indeed much better. To accomplish this, the `computed`
decorator would be roughly written as

```js
function computed(...deps) {
  return function(target, name, descriptor) {
var undecorated = descriptor.value;
descriptor.value = undecorated.apply(this, deps.map(dep =>
this.get(dep));
return descriptor;
  };
}
```

The above is meant merely for illustrative purposes.

The sweetness of the resulting sugar should attract a fair number of flies.

--
Bob

On Tue, Oct 20, 2015 at 6:30 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Decorators for functions

[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:
> 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 instantly no idea if I'm exporting an object
> through decorators and methods or just functions.
>
> True that methods won't have the `function` bit but we're  back to the
> portability issue I've mentioned, which is not just a bump in the road, it's
> a lock in ES6 only, transpiled or not, which reminds me issues with modules
> between Python 3 and 2 ... I wish we'd never go even close to that situation
> with decorators, which are powerful and right now portable.
>
> Are we really willing to lose current portability considering there is a
> simple work around and even the only dev with concrete examples is not sold
> it's a good approach rather than just a more confusing one?
>
> Wouldn't be wise to eventually bring in current proposal and reserve
> eventually the function bit for 2017 so that the migration to the new
> decorator feature would be less problematic?
>
> After all I don't see any problem in implementing the idea later on so that
> going out with just current proposal is past and future friendly.
>
> Again just my thoughts
>
> Regards
>
>
> On Tue, Oct 20, 2015 at 3:40 PM, Frankie Bagnardi 
> wrote:
>>
>> 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
>> @web.method('post')
>> @web.parsesJSON()
>> @web.expectsBody({
>>   emailAddress: String, password: String,
>> })
>> function handleLogIn(req, res, body){
>>   // ...
>> }
>> ```
>>
>> In this example we have a React component that's just a simple function.
>> We want to wrap it with a high order component.
>>
>> ```js
>> @providesSomething()
>> function MyComponent({something}){
>>   // ...
>> }
>> ```
>>
>> Here we're using dependency injection:
>>
>> ```js
>> @di.provide(Calculator)
>> function add(calc, a, b){
>>   return calc.add(a, b);
>> }
>>
>> add(1, 2) === 3
>> ```
>>
>> I'm not completely sold on if these are good ideas. It might be more
>> confusing than it's worth.
>>
>>
>> On Tue, Oct 20, 2015 at 7:23 AM, Eli Perelman  wrote:
>>>
>>> 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 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 exploding the number of
 rules which must be remembered in order to use that feature.


 ___
 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
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Isiah Meadows
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Decorators for functions

[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 instantly no idea if I'm exporting an object
through decorators and methods or just functions.

True that methods won't have the `function` bit but we're  back to the
portability issue I've mentioned, which is not just a bump in the road,
it's a lock in ES6 only, transpiled or not, which reminds me issues with
modules between Python 3 and 2 ... I wish we'd never go even close to that
situation with decorators, which are powerful and right now portable.

Are we really willing to lose current portability considering there is a
simple work around and even the only dev with concrete examples is not sold
it's a good approach rather than just a more confusing one?

Wouldn't be wise to eventually bring in current proposal and reserve
eventually the function bit for 2017 so that the migration to the new
decorator feature would be less problematic?

After all I don't see any problem in implementing the idea later on so that
going out with just current proposal is past and future friendly.

Again just my thoughts

Regards


On Tue, Oct 20, 2015 at 3:40 PM, Frankie Bagnardi 
wrote:

> 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
> @web.method('post')
> @web.parsesJSON()
> @web.expectsBody({
>   emailAddress: String, password: String,
> })
> function handleLogIn(req, res, body){
>   // ...
> }
> ```
>
> In this example we have a React component that's just a simple function.
> We want to wrap it with a high order component.
>
> ```js
> @providesSomething()
> function MyComponent({something}){
>   // ...
> }
> ```
>
> Here we're using dependency injection:
>
> ```js
> @di.provide(Calculator)
> function add(calc, a, b){
>   return calc.add(a, b);
> }
>
> add(1, 2) === 3
> ```
>
> I'm not completely sold on if these are good ideas. It might be more
> confusing than it's worth.
>
>
> On Tue, Oct 20, 2015 at 7:23 AM, Eli Perelman  wrote:
>
>> 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 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 exploding the number of
>>> rules which must be remembered in order to use that feature.
>>>
>>>
>>> ___
>>> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Decorators for functions

[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
@web.method('post')
@web.parsesJSON()
@web.expectsBody({
  emailAddress: String, password: String,
})
function handleLogIn(req, res, body){
  // ...
}
```

In this example we have a React component that's just a simple function. We
want to wrap it with a high order component.

```js
@providesSomething()
function MyComponent({something}){
  // ...
}
```

Here we're using dependency injection:

```js
@di.provide(Calculator)
function add(calc, a, b){
  return calc.add(a, b);
}

add(1, 2) === 3
```

I'm not completely sold on if these are good ideas. It might be more
confusing than it's worth.


On Tue, Oct 20, 2015 at 7:23 AM, Eli Perelman  wrote:

> 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 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 exploding the number of
>> rules which must be remembered in order to use that feature.
>>
>>
>> ___
>> 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

Re: Decorators for functions

[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 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 exploding the number of
> rules which must be remembered in order to use that feature.
>
>
> ___
> 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

Re: Decorators for functions

[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 exploding the number of rules
which must be remembered in order to use that feature.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Decorators for functions

[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* in JavaScript
potentially has side effects.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Decorators for functions

[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 
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  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 ou

Re: 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.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  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 functi

Re: Decorators for functions

[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 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  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, 

Re: Decorators for functions

[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 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 
> 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

Re: Decorators for functions

[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 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 
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
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
> rauschma.de
>
>
>
> ___
> 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

Decorators for functions

[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 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



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss