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
