arrows and a proposed softCall

Brendan Eich brendan at mozilla.com
Mon Jun 4 15:46:58 PDT 2012


Angus Croll wrote:
> On Mon, Jun 4, 2012 at 9:54 AM, Brendan Eich <brendan at mozilla.com 
> <mailto:brendan at mozilla.com>> wrote:
>
>     You mean you still propose that (=> 42).call({}) should throw, but
>     (function () { return 42; }).call({}) should not?
>
>     Sorry, this isn't a principled response. There should be no
>     difference in result between those two cases.
>
>
> I disagree. You yourself said "so are you looking for an isBound 
> predicate just to throw an error? I'm not saying that is a non-goal".

There's no isBound test in the above, though.

The topic was an incompatible change to .apply and .call where the left 
of dot is some (not all) bound-this/no-this forms and the arg-list to 
the right starts with a non-null |thisArg|.

Compatibility says we can't change the bound (as in ES5 bind) and 
no-this cases (pre-ES5, e.g. PrototypeJS bind, or var self=this;... self 
open coded solutions) behavior. Ok, but you're right, arrows are new, we 
could throw on non-null |thisArg| presented to someArrow.call or.apply.

But the example I showed is just a refactoring (shortening or 
lengthening). There's no isBound test, no use of .prototype, etc. That's 
why i wrote "in principle". If you change to a different apples vs. 
oranges (or apples vs. apples) setting, principles may differ.

> The principal is let the user know they are trying to set |this| in a 
> hard bound function.

That's not a general principle, though. Andreas called out functions 
that ignore one parameter among N, vs. those that do not. We don't have 
an "isParameterUsed(name)" magic predicate on functions that can take a 
formal parameter name and tell us the same thing you want for |this| in 
the form of isBound().

Not that there's anything wrong with isBound -- the point is by what 
principle do you distinguish |this| from other parameters that could be 
ignored?

> The level of introspection required to go the extra mile and look for 
> |this| usage seems neither desirable or useful.

Sorry, not sure I followed this sentence. Do you mean by "level of 
introspection" the pain of Function.prototype.toString searching, say 
using a regexp, to see if any "this" word occurs? Or more complete: a 
full parse of function source?

If so, I get it and agree.

> If my function doen't reference |this| then I don't care if |this| is 
> modifiable.

I agree but why doesn't this apply to arrows as well? The issue is not 
whether the callee ignores or binds |this|, it is whether the caller 
expects to override |this| and it has a callee that doesn't care (in 
which case a thrown error could be better than proceeding). Or so I 
thought you were saying!

> However I thought we had some agreement that -> was a valid goal. In 
> which case this error throwing stuff is less important (to me at least)

You and I agree on -> but (a) it's not in ES6 and not actively proposed; 
(b) how does this relieve the concern that people will pass arrows (or 
other bound-this and no-this functions) to an API whose contract 
requires dynamic |this|?

/be


More information about the es-discuss mailing list