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 ;-)
On Wed, Jun 17, 2015 at 8:40 PM, Jussi Kalliokoski <
jussi.kallioko...@gmail.com> wrote:
> On Wed, Jun 17, 2015 at 10:35 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> 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 <
>> jussi.kallioko...@gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, Jun 17, 2015 at 7:13 PM, Allen Wirfs-Brock <
>>> al...@wirfs-brock.com> 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
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
