Angus Croll wrote:
On Mon, Jun 4, 2012 at 9:54 AM, Brendan Eich <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
