Scoped binding of a method to an object

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

On 15 October 2013 17:51, Allen Wirfs-Brock <allen at> wrote:
> On Tue, Oct 15, 2013 at 3:39 AM, Andreas Rossberg <rossberg at>
> wrote:
>> On 15 October 2013 03:09, Allen Wirfs-Brock <allen at> 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
> I'd be quite comfortable with saying:
> >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
> <>
>     var bind = Function.prototype.bind;
>     var uncurryThis = bind.bind(;
> or, in a slightly less obscure formulation that ignores "safety"):
> let uncurryThis = f=>((a0, ...args)=>f.apply(a0, args))
> although, I still content that
> 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.


More information about the es-discuss mailing list