Good point. You're absolutely right, that sounds much cleaner. And it still lets me shoot myself in the foot by passing and modifying an object ;)
Yes - hopefully, people don't go mutating the context object, but they certainly can if they want to. I guess there's incentive for users of the context API to use a frozen object as the context value, to ensure mutations don't happen, but any foot-shooters out there are free to not do so.
Technically true, but in my experience it's more common to treat it as an implicit parameter: like formal parameters, and unlike dynamic scope (or this proposal), you need only look at the direct caller to determine the value of the this binding, rather than needing to walk potentially arbitrarily far up the call stack. (Modulo details about arrows and bind, of course.)
In any case, "like this, but more complicated" would be also be a hard sell.
2 Likes
The way I read the OP, it's like Function.prototype.call for custom slots. Not necessarily more complicated that this (from the user point of view).
The difference is that Function.prototype.call() only sets the this binding for that specific function being called - that this binding does not automatically propagate to other functions called from it.
For example:
const ctx = new Context()
ctx.use(2, function() {
f()
})
function f() {
g()
}
function g() {
console.log(ctx.get()) // 2
}
Notice how the value of the context is automatically available to any functions up the call stack. This isn't the case with this binding, and this is the "magic" that will probably be the primary concern with this proposal.
1 Like
Okay, I've redone the proposal (again) to be a little less pointed towards a solution and a little more focused on the problem. Feel free to cut an issue against the repo if something isn't clear, or if you have more examples that could be added.
1 Like