default this binding for ES-next strict mode.

Currently in ES5 strict mode the value of `this` is `undefined` by default.

function foo() {
  return this;
}

foo(); // undefined

function foo() {
  return (function () {
    return this;
  }());
}

foo.call(o); // undefined

Since the default value of `this` is always undefined, the `var that =
this;` or `var self = this;` pattern has occurred. An alternative to this
pattern is using .bind on a function.

var Obj = {
  method: function () {
    var that = this;
    el.addEventListener("click", function () {
       that.doSomethingElse();
    });
  }
}

Basically whenever a javascript developer want's to do an asynchronous
operation using a closure inside a method he has to keep a handle on the
value of `this` because the value of `this` inside the closure is useless.
This is more common in environments where asynchronous operations are more
common, like node.js.

What if we changed the value of `this` inside local function declarations
to be the value of this in the outer function. That would mean

function foo() {
  return (function () {
    return this;
  }());
}

foo.call(o); // o

Pros:
 - Removes the majority of the use-cases for `var that = this`
 - Puts a value of `this` to good use rather then being `undefined`.

Cons:
 - Makes `this` more "confusing"
 - Breaks ES5 strict code that assumes `this === undefined`

Personally I say that value of `this` is undefined in ES5 strict. So nobody
uses it. So this is an optional addition that would make life easier for
people who want to use it.

Optional: Change the value of `this` to be the outer function `this` in
non-strict mode (breaking a large amount of code. I don't think we can get
away with that).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111118/9e2db914/attachment.html>

> What if we changed the value of `this` inside local function declarations to be the value of this in the outer function.

I’d love this to work!

Alas, the value of `this` has to be determined dynamically. Mark Miller gave a good example why that’s bad (when I recently suggested the same thing):
http://www.mail-archive.com/[email protected]/msg11194.html

Axel

-- 
Dr. Axel Rauschmayer
axel at rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

One more comment: fixing the `this` problem is why I like lambda blocks so much: They can only be used in a non-method capacity and the meaning of `this` does not have to change, dynamically, any more – it is always lexically bound.

On Nov 18, 2011, at 22:18 , Jake Verbaten wrote:

> Currently in ES5 strict mode the value of `this` is `undefined` by default.
> 
> function foo() {
>   return this;
> }
> 
> foo(); // undefined
> 
> function foo() {
>   return (function () {
>     return this;
>   }());
> }
> 
> foo.call(o); // undefined
> 
> Since the default value of `this` is always undefined, the `var that = this;` or `var self = this;` pattern has occurred. An alternative to this pattern is using .bind on a function.
> 
> var Obj = {
>   method: function () {
>     var that = this;
>     el.addEventListener("click", function () {
>        that.doSomethingElse();
>     });
>   }
> }
> 
> Basically whenever a javascript developer want's to do an asynchronous operation using a closure inside a method he has to keep a handle on the value of `this` because the value of `this` inside the closure is useless. This is more common in environments where asynchronous operations are more common, like node.js.
> 
> What if we changed the value of `this` inside local function declarations to be the value of this in the outer function. That would mean
> 
> function foo() {
>   return (function () {
>     return this;
>   }());
> }
> 
> foo.call(o); // o
> 
> Pros: 
>  - Removes the majority of the use-cases for `var that = this`
>  - Puts a value of `this` to good use rather then being `undefined`.
> 
> Cons:
>  - Makes `this` more "confusing"
>  - Breaks ES5 strict code that assumes `this === undefined`
> 
> Personally I say that value of `this` is undefined in ES5 strict. So nobody uses it. So this is an optional addition that would make life easier for people who want to use it.
> 
> Optional: Change the value of `this` to be the outer function `this` in non-strict mode (breaking a large amount of code. I don't think we can get away with that).
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-- 
Dr. Axel Rauschmayer
axel at rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111118/54a255fb/attachment-0001.html>

On Fri, Nov 18, 2011 at 9:30 PM, Axel Rauschmayer <axel at rauschma.de> wrote:

> > What if we changed the value of `this` inside local function
> declarations to be the value of this in the outer function.
>
> I’d love this to work!
>
> Alas, the value of `this` has to be determined dynamically. Mark Miller
> gave a good example why that’s bad (when I recently suggested the same
> thing):
> http://www.mail-archive.com/[email protected]/msg11194.html


I don't think that's neccessarily a bad thing. If you ask me, it's a poor
counter example because innerPoint should not be defined inside Outer.

I defiantly see the problem with the value of `this` leaking through any
closures you return. I'm not sure whether this is particularly bad. It's
just something people need to be aware of.

Of course this adds two more cons

Cons:
 - outer value of `this` leaks through returned closures
 - code that used to throw an error, will now work with unexpected side
effects.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111118/50ed0e1d/attachment.html>