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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> >>> 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 >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Isiah Meadows _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
