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 <f.bagnardi at gmail.com>
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 <eli at eliperelman.com> 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 <zenparsing at gmail.com>
>> 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 at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151020/2ec1b7d6/attachment-0001.html>