<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jun 17, 2015, at 8:09 AM, Andrea Giammarchi wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Mostly every Array extra in ES5 would work with those functions, e.g.<div><br></div><div>```js</div><div><div style="font-size:12.8000001907349px"><span style="font-family:monospace,monospace">function multiplyPoints (_p2) {<br></span></div><div style="font-size:12.8000001907349px"><span style="font-family:monospace,monospace">  var { x1: x, y1: y } = this;<br></span></div><div style="font-size:12.8000001907349px"><span style="font-family:monospace,monospace">  var { x2: x, y2: y } = _p2;<br></span></div><div style="font-size:12.8000001907349px"><span style="font-family:monospace,monospace">  return { x: x1 * x2, y: y1 * y2 };<br>}</span></div></div><div style="font-size:12.8000001907349px"><span style="font-family:monospace,monospace"><br></span></div><div style="font-size:12.8000001907349px"><span style="font-family:monospace,monospace">var multiplied = manyPoints.map(</span><span style="font-family:monospace,monospace;font-size:12.8000001907349px">multiplyPoints, centralPoint</span><span style="font-family:monospace,monospace;font-size:12.8000001907349px">);</span></div><div>```</div><div><br></div><div>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.<br></div><div><br></div><div>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</div><div><br></div></div></blockquote><br></div><div>It seems to me that  we already can quite nicely express in ES6 the use of a function as a method:</div><div><br></div><div><div>```js</div><div>function multiplyPoints({x1, y1}, {x2,y2}) {</div><div>    return { x: x1 * x2, y: y1 * y2 }</div><div>}</div><div><br></div></div><div><div>class Point {</div><div>   multiply(p2) {return multiplyPoints(this, p2)}</div><div>}</div><div>```</div></div><div><br></div><div>or, perhaps a bit more OO</div><div><br></div><div>```js</div><div>class Point {</div><div>   static multiply({x1, y1}, {x2,y2}) {</div><div>      return new Point(x1 * x2, y1 * y2 )  //or new this(...) if you care about subclassing Point</div><div>   }</div><div><br></div><div>   multiply(p2) {return Point.multiply(this, p2)}</div><div><br></div><div>   constructor(x,y) {</div><div>      this.x = x;</div><div>      this.x = y;</div><div>   }</div><div>}</div>```<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>`this` is an OO concept.  FP people, `this` is not for you;  don't use it, don't try to "fix it". </div><div><br></div><div>Allen</div><div><br></div><div><br></div></body></html>