On Wed, Jun 17, 2015 at 10:45 PM, Andrea Giammarchi < [email protected]> wrote:
> the ::bind syntax is OK (I don't really like that double colon 'cause it's > not semantic at all with the single colon meaning but I can live with it) > but having potential bitwise-like operators around to adress a possible > context ... well, I wouldn't probably use/need that in the short, or even > long, term. > > Again, just my opinion, listen to others ;-) > Ah sorry, my bad, I misunderstood you. :) To clarify, I've only heard positive feedback from people of the bind syntax; as for this proposal, this thread is the first time I hear feedback and it doesn't seem overtly positive. :P > > On Wed, Jun 17, 2015 at 8:40 PM, Jussi Kalliokoski < > [email protected]> wrote: > >> On Wed, Jun 17, 2015 at 10:35 PM, Andrea Giammarchi < >> [email protected]> wrote: >> >>> 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) >>> >> >> To each their own. :) I personally really like the bind syntax and have >> received a tremendously positive feedback on it - the Trine project alone >> has received over 1000 stars on GitHub, in under a week since release (last >> Thursday), and it's just showcasing a part of the power of the proposed >> syntax. >> >> >>> >>> 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
