Naming bikeshed

[bakkot]

Never too early for a naming bikeshed! (This need not be resolved until going for stage 3, of course.)

I've always called this uncurryThis, which I think is a more precise description of what it does than unThis. That's also what I've seen it called elsewhere: x, x, etc.

[js-choi]

(See also prior discussion to tc39/proposal-function-helpers#17.)

I would be more comfortable with using the word “uncurry” if “curry” was a term used anywhere else in the core language, but it’s not used anywhere else in the language, and so that’s at least two steps for a learner to understand: (1) what function currying is and (2) what “uncurrying” therefore is. Someone cannot understand “uncurrying” without understanding “currying”, which is a concept that is present nowhere else in the core language. Yes, currying is common enough in a lot of (but not all) functional-programming styles, but, as you know, several TC39 members are against introducing currying elsewhere in the core language (due to performance concerns, ecosystem-schism concerns, aesthetic concerns, etc.); see tc39/proposal-pipeline-operator#221. And unless currying is present elsewhere in the core language, I am reluctant to introduce uncurrying to the core language too. 🍛

@ljharb’s “callBind” library is also often used, but the “callBind” name comes from how callBind(fn) is equivalent to fn.call.bind(fn), which is also pretty esoteric.

“unThis” is the simplest name I can think of right now that describes what it does: it gets rid of this from functions that previously used this; it un-this-ifies functions.

But I’m open to whatever name. 🎨🚲🏠

[ljharb]

I very much do not like "uncurryThis", because currying is a confusing advanced concept that we shouldn't be promoting, and understanding "uncurry" requires one understands "curry".

I also don't like unThis, it doesn't get rid of this from the function it's applied to - it just unshifts the receiver into the first argument position.

I certainly prefer "callBind" - the reason I named the package that way is because it's literally Function.call.bind(f).

[js-choi]

I also don't like unThis, it doesn't get rid of this from the function it's applied to - it just unshifts the receiver into the first argument position.

@ljharb: Your point here is well taken, but I would say that insofar that we can call a function that uses the this binding a “this-using function”, then any function returned by unThis or whatever is always a function that never uses the this binding (a “non-this-using function”). So I think we can really think of it as a function in which the this binding used to be involved but now is no longer involved (as with all bound functions).

The original function doesn’t change, and a new function is returned, but we do often use verbs to denote pure non-mutating functions as if they were mutating its input in place, instead of returning a new copy. (We could take a page from proposal-change-array-by-copy and call it withoutThis or withThisAsArg, I guess.)

But if you think that callBind is easier to teach and reason about, then I certainly will take that into consideration.

• fn.callBind()
• fn.uncurryThis()
• fn.unThis()
• fn.withoutThis()
• fn.withThisAsArg()
• fn.thisAsArg()

[ljharb]

if you think that callBind is easier to teach and reason about

I do, because of the way it'd be naively polyfilled, as Function.call.bind(f) or f.call.bind(f).

[theScottyJam]

I don't like callBind that much. It's based on the "call" function with already provides no descriptive value for what it does, and is easily confused with the apply function. Then we're tacking on "bind" after it, and we're left with an even worse name.

I hope the bind-this syntax proposal can help people forget that .call() and .apply() was ever a thing, and we can provide a better name from the start for a function like this, instead of using a name that harkens back to functions that'll become almost useless once bind-this syntax is in.

Edit: I'll also add, the first time I saw a callBind definition, I almost had to set down with a pencil and paper to figure out what was going on. (the .call() make the "this" arg the first param, but then the bind is binding a this arg, but wait, it's being called on .call(), not on the instance, so the "this" value we're dealing with in .bind() is a different one then what .call() is dealing with, and... now I'm lost)

[bakkot]

I strongly dislike callBind. It's a.) naming it after an implementation detail and b.) requires users to know what call and bind do.

[bakkot]

A problem with unThis is that it implies it would only work once, and then be a no-op (and would be a no-op on an arrow or any other function which already doesn't use this). But that's not actually what's proposed (I assume): every time you call it uncurries this again, pushing the original parameters out by one.

[theScottyJam]

unThis does feel like a name I could get used to, but I agree that it's a little confusing on first site. It sort of reads as "take this function, and make it so it doesn't accept a 'this' anymore", which is only half correct.

The word "uncurry" doesn't feel like it belongs here either. I see the relationship, but it sort of stretches its definition.

thisAsArg() is so far my favorite. It's a bit of a mouthful, but it's still short, and it's clear. But, I do still like unthis().

[ljharb]

imo it's not an implementation detail - "binding Function.prototype.call" is the semantics it has. It does require users know what call and bind do, but I don't see why that's a problem - this proposal already requires users to know pretty intimately how function calling and this works.

[theScottyJam]

Another problem with callBind is that it doesn't even do a great job of explaining the semantics either. Someone who has an intuition of .call() and .bind(), and who sees .callBind() could very well assume that the underlying implementation went something like this:

Function.prototype.callBind = function(thisArg, ...args) {
  return this.call(thisArg, ...args).bind(thisArg)
}

or some other similar implementation. There's lots of ways to combine those two actions.

The name "callBind" sounds like you're first using .call(), then you're using .bind(). Similar to how .flatMap() has you first use .flat() then use .map(). In reality, you're not actually calling .call(), you're just binding to it.

[ljharb]

The actual semantics of flatMap are "map, then flat".

[theScottyJam]

Whoops, you're right. Still though, you're performing both of those actions, while a callBind is not doing both a .call() and a .bind().

[js-choi]

A problem with unThis is that it implies it would only work once, and then be a no-op (and would be a no-op on an arrow or any other function which already doesn't use this). But that's not actually what's proposed (I assume): every time you call it uncurries this again, pushing the original parameters out by one.

@bakkot: If unThis that strongly implies an in-place mutation of the original function object, then how do you feel about .thisAsArg() (or .withThisAsArg())? I think they do a better job avoiding that mutating-the-original feeling.

[bakkot]

strongly implies an in-place mutation of the original function object

Sorry, I didn't mean to say it implied in-place mutation. I don't think it does. Rather, the problem is that it implies that f.unThis().unThis() will behave the same as f.unThis(), or that arrow.unThis() will behave the same as arrow, neither of which are true.