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 <rtm at gol.com> 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.giammarchi at gmail.com> wrote:
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151020/f399d667/attachment-0001.html>