Named `this` and `this` destructuring

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Thu Jun 18 05:24:38 UTC 2015


On Wed, Jun 17, 2015 at 10:45 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> 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 <
> jussi.kalliokoski at gmail.com> wrote:
>
>> On Wed, Jun 17, 2015 at 10:35 PM, Andrea Giammarchi <
>> andrea.giammarchi at 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.kalliokoski at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jun 17, 2015 at 7:13 PM, Allen Wirfs-Brock <
>>>> allen at 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 at mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150618/f5ceb125/attachment.html>


More information about the es-discuss mailing list