Scoped binding of a method to an object

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Oct 15 08:51:17 PDT 2013


On Oct 15, 2013, at 6:40 AM, Mark S. Miller wrote:

> 
> 
> 
> On Tue, Oct 15, 2013 at 3:39 AM, Andreas Rossberg <rossberg at google.com> wrote:
> On 15 October 2013 03:09, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> > I still don't get why so many JS programmer with a FP orientation want  to do things with the |this| binding.   |this| is for us OO geeks, if you are doing FP you don't need it.
> 
> Well, 'this' comes up because you cannot avoid having to interface
> with OOish APIs that conflicts with FPish composition patterns. For
> example, you'd like to be able to do something like
> 
>   array.map(String.prototype.toLowerCase)
> 
I'd be quite comfortable with saying:
          array.map(str=>str.toLowerCase())

It preserves the integrity of of the string abstraction rather than just assuming that the naked String.prototype.toLowerCase function is the appropriate one for any particular str value.

> Using <http://wiki.ecmascript.org/doku.php?id=conventions:safe_meta_programming>
> 
>     var bind = Function.prototype.bind;
>     var uncurryThis = bind.bind(bind.call);
or, in a slightly less obscure formulation that ignores "safety"):

let uncurryThis = f=>((a0, ...args)=>f.apply(a0, args))

> 
>     array.map(uncurryThis("".toLowerCase))
> 

although, I still content that  

        array.map(str=>str.toLowerCase())

is the better formulation. (and fewer characters for those who worry about such things)

> 
> But map expects a function, while toLowerCase is only available as a
> method. So unless you rewrap all relevant APIs in functional style you
> have to deal with 'this' in one form or the other, and going back and
> forth is not pretty with what JS currently offers. (Mind you, a bind
> operator does not even address this particular example.)
> 
> /Andreas
> 

I think arrow functions are the appropriate syntactic convenience and since this started as a discussion of the :: extension we can assume arrows already exist.

We need to know and respect abstraction boundaries. I think careful thought is called for each time you cross the FP/OO boundary.  You can't just assume that the a function you extracted from a method property is the right function to use with other objects.  You can't just assume that the |this| value of a method corresponds to the first parameter of a function (or visa vera).

Just because we know how an object is build out of functions, you shouldn't routinely take an object abstraction I've created and rip it apart into ins more primitive constituent elements  which you then repurpose.  To me, this is analogous  to talking a function apart into its machine level code sequences and data structures and then doing clever things with them. It's possible, it might even be necessary in some very unusual situation, but it should never be routine.

Allen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131015/5eaabb10/attachment.html>


More information about the es-discuss mailing list