making |this| an error (was Re: for own(...) loop)
The forEach method might not do what you expect it to. This can not be statically determined.
On 9 November 2011 16:10, John J Barton <johnjbarton at johnjbarton.com> wrote:
I'm sure this has been discussed before, but isn't is possible and desirable to make |this| illegal in "using strict;" when it can be determined from the AST alone that |this| will bind to |window|? eg:
Object.keys(foo).forEach(function(key) { // this is undefined-> window });
How do you know statically that `this' would be undefined? Somebody might have modified forEach.
In JavaScript, you generally don't know a whole lot of things statically.
On Wed, Nov 9, 2011 at 7:22 AM, Peter van der Zee <ecma at qfox.nl> wrote:
The forEach method might not do what you expect it to. This can not be statically determined.
And if forEach is not what you expect, that function may bind its argument: foo(function() { do something with |this| }); function foo(fn) { bar.fn()};
I suppose it's more of a lint thing then.
jjb
2011/11/9 John J Barton <johnjbarton at johnjbarton.com>
I'm sure this has been discussed before, but isn't is possible and desirable to make |this| illegal in "using strict;" when it can be determined from the AST alone that |this| will bind to |window|? eg:
Object.keys(foo).forEach(function(key) { // this is undefined-> window });
This case kind of case is because, as others have noted, incorrect |this| binding most often occurs in two cases: 1) mixed OO and functional programming (as above) and 2) callback defn.
In strict-mode', |this| would resolve toundefined' inside that function
anyways. I'm not a fan of making constructs "illegal" just because
their semantics might be confusing, even more so when such
disallowance would vary highly in context. It would be bound to
make things more confusing, imho.
Block lambdas are the best solution I can see right now.
On Wed, Nov 9, 2011 at 3:41 AM, David Bruant <bruant.d at gmail.com> wrote:
I'm sure this has been discussed before, but isn't is possible and desirable to make |this| illegal in "using strict;" when it can be determined from the AST alone that |this| will bind to |window|? eg:
Object.keys(foo).forEach(function(key) { // this is undefined-> window });
This case kind of case is because, as others have noted, incorrect |this| binding most often occurs in two cases: 1) mixed OO and functional programming (as above) and 2) callback defn.
Perhaps it is harder to detect than I think.
jjb
On Wed, Nov 9, 2011 at 3:41 AM, David Bruant <bruant.d at gmail.com> wrote: > Le 09/11/2011 02:26, Andrew Paprocki a écrit : >> >> On Tue, Nov 8, 2011 at 6:36 PM, Brendan Eich<brendan at mozilla.com> wrote: >>> >>> Ignoring performance, a lot of stylish JS hackers use >>> Object.keys(o).forEach. How many run into the wrong |this| >>> (arguments/break/continue/return)? Not clear. Something to study. >> >> I was curious so I did some grok-ing across my code sample and >> Object.keys() is barely used. The usage of the |for in| construct is 2 >> orders of magnitude larger than the usage of hasOwnProperty(), >> supporting the thought that no one really does it the "right" way. >> >> The MDN page for Object.keys does not talk about |this| being wrong in >> certain situations. If you could elaborate on that, it would be >> helpful to know. > > The |this| differs between the body of a for-in and the argument callback in > the .forEach. Nothing to do with Object.keys. .forEach has a second optional > argument which is the value to be used as |this| so that you don't have to > do a .bind. I'm sure this has been discussed before, but isn't is possible and desirable to make |this| illegal in "using strict;" when it can be determined from the AST alone that |this| will bind to |window|? eg: Object.keys(foo).forEach(function(key) { // this is undefined-> window }); This case kind of case is because, as others have noted, incorrect |this| binding most often occurs in two cases: 1) mixed OO and functional programming (as above) and 2) callback defn. Perhaps it is harder to detect than I think. jjb