OK **that one** I've no idea what supposes to improve exactly ... I should have tried to realize your proposal better, apologies.
After seeing that, I probably agree with Allen at this point we don't really need that kind of syntax around JS (still IMHO, of course) Best Regards On Wed, Jun 17, 2015 at 6:01 PM, Jussi Kalliokoski < [email protected]> wrote: > > > On Wed, Jun 17, 2015 at 7:13 PM, Allen Wirfs-Brock <[email protected]> > wrote: > >> >> On Jun 17, 2015, at 8:09 AM, Andrea Giammarchi wrote: >> >> Mostly every Array extra in ES5 would work with those functions, e.g. >> >> ```js >> function multiplyPoints (_p2) { >> var { x1: x, y1: y } = this; >> var { x2: x, y2: y } = _p2; >> return { x: x1 * x2, y: y1 * y2 }; >> } >> >> var multiplied = manyPoints.map(multiplyPoints, centralPoint); >> ``` >> >> It's not that common pattern but it gives you the ability to recycle >> functions as both methods or filters or mappers or forEachers and >> vice-versa. >> >> I personally use those kind of functions quite a lot to be honest, most >> developers keep ignoring Array extra second parameter as context though, >> they probably use a wrapped fat arrow within an IFI with call(context) :D >> >> >> It seems to me that we already can quite nicely express in ES6 the use >> of a function as a method: >> >> ```js >> function multiplyPoints({x1, y1}, {x2,y2}) { >> return { x: x1 * x2, y: y1 * y2 } >> } >> >> class Point { >> multiply(p2) {return multiplyPoints(this, p2)} >> } >> ``` >> >> or, perhaps a bit more OO >> >> ```js >> class Point { >> static multiply({x1, y1}, {x2,y2}) { >> return new Point(x1 * x2, y1 * y2 ) //or new this(...) if you care >> about subclassing Point >> } >> >> multiply(p2) {return Point.multiply(this, p2)} >> >> constructor(x,y) { >> this.x = x; >> this.x = y; >> } >> } >> ``` >> >> Regardless of how you express it, if you want the same function to be >> used both as a standalone function and as an method, you are going to have >> to have a line or two of code to install the function as a method. To me, >> the one-line method definitions used above are about as concise and much >> clearer in intent than `Point.prototype.multiply=multiplyPoints;` or >> whatever other expression you would use to install such a function as a >> method. And I would expect any high perf JIT to use inlining to completely >> eliminate the indirection so, where it matters, there probably wound't be >> any performance difference. >> >> Many JS programmers have historically been confused about the JS >> semantics of `this` because it is over-exposed in non-method functions. >> Things like the current proposal increases rather than mitigates the >> potential for such confusion. if you are programming in a functional style, >> don't write functions that use `this`. If you need to transition from >> to/from OO and functional styles, be explicit as shown above. >> >> `this` is an OO concept. FP people, `this` is not for you; don't use >> it, don't try to "fix it". >> > > But I already am [1][1], and it allows for a much nicer syntax than > functions that don't use `this`, and also composes well with built-ins > (other than Object.*) This proposal is building on the proposed function > bind syntax [2][2]. > > More examples of the power of the bind syntax can be found in the links, > but the bind syntax combined with my proposal would for example allow this: > > ```JS > function add (&a, b) { return a + b; } > > 2::add(3) // 5 > ``` > > [1]: https://github.com/jussi-kalliokoski/trine > [2]: https://github.com/zenparsing/es-function-bind > >> >> Allen >> >> >> >> _______________________________________________ >> 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
