Named `this` and `this` destructuring

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Wed Jun 17 17:01:04 UTC 2015


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/20150617/090db2c5/attachment.html>


More information about the es-discuss mailing list