Scoped binding of a method to an object

Andreas Rossberg rossberg at google.com
Wed Oct 16 03:39:27 PDT 2013


On 15 October 2013 17:51, Allen Wirfs-Brock <allen at wirfs-brock.com> 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.

Yes, lambdas make it better. However, some more higher-order FP
patterns are significantly more pleasant in point-free style. Not sure
they matter much for common JS practice, though.

> 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)

Agreed. Any call that contains more than a single occurrence of
apply/call/bind is just obfuscated code (and likely rather inefficient
as well).

> 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.

I agree with most you say, and it's unfortunate that JS allows unsafe
method extraction / this-stealing in the first place. But I wouldn't
put the specific cases I'm alluding to into that category. They are
mostly about bridging syntax asymmetries.

/Andreas


More information about the es-discuss mailing list