someClass.self = this;


Jonathan Snook said on December 18, 2006

All you've done is assigned the current context to a property of the object. However, from your example, it's hard to say how you intend to use your object. As a result, you may still be relying on closures to access the object.

James Bennett said on December 18, 2006

I waffle on this.

Several of the good toolkits go out of their way to ensure that this gets corrected to what it intuitively "should" be, and this is generally handy.


Sometimes the workarounds to get fine-grained correction of this just get too cumbersome, and I either resort to closures or find some other way to get an object instance passed to event handlers (I know that YUI makes that fairly easy, with quite a few useful optional arguments to its addListener).

So for now I'm doing bits of both, but I feel myself migrating away from use of this and toward other tricks (with the result that my JS starts looking more like my Python, having instances passed explicitly to methods).

Randy said on December 18, 2006

Hmmm... I am still somewhat partial with this. Sometimes it just seems simpler. Good points though.

Oh, and where you talk about Call and Apply I think you have a typo:
"mytext.call(obj)" should be "mytest.call(obj)" to jive with your example.

TJ said on December 18, 2006

I typically go with the "single object" method. It resembles namespaces, and not only helps you keep your data together, it prevents function naming conflicts when using multiple scripts.

Cory Smith said on December 18, 2006

A variation on avoiding the transient nature of this is to avail yourself on the arguments.callee property.

  function aListener( e ){
     var self = arguments.callee;
  aListener.aMethod = function(){

It is more functional and compact, hence less readable, but it does have some unique uses that suggest it for specialized situations, like RegExp callbacks, and reusable listeners.

And, depending on your browser, it may provide smaller memory footprint, du to the fewer Function objects being created. This may or may not matter.

Andy Kant said on December 18, 2006

I tend to use a combination. The 'this' pointer is important because it is required to access instance variables from prototype methods. I use closures to reference 'this' for everything that might be called outside of the normal context (anything called by another member function). I could use the '.call' or '.apply' but I found that sometimes that breaks (probably my error) and it just makes my code uglier to look at and maintain.

On a sort of related note, while figuring out how I should handle 'this' pointers I created a method of having quasi-protected variables. It gives me a way to access private variables from other objects/classes while also hiding them from the public interface. The downside is that private variables are now potentially exposed for anyone to alter.

function Obj() {
var _self = this;
this.value = 99;
this.$expose = function(prop) {
return eval('(' + prop + ')');
var _helper = function(multiplier) {
_self.value *= multiplier;

Obj.prototype.square = function() {

Andrew Tetlaw said on December 18, 2006

I agree, in a lot of cases it's easier to use the 'single object' technique. I find it easier & safer to use and easier to read.

Jeremy Keith said on December 19, 2006

I absolutely agree about using closures instead of this. Nine times out of ten, it's easier to read and understand as well as being more portable.

Tim McCormack said on December 20, 2006

I've never really seen the need for the this keyword. After closures, object-based namespacing, and simulated private/protected variables -- who needs this?

Frank Manno said on February 17, 2007

Hey Jon,

Not sure if you're still checking comments from this post, but after having read your suggestion on using closures, the one thing that came to mind was memory leaks.

Would there be a need for memory concerns in this context?

Jonathan Snook said on February 17, 2007

@Frank: using closures doesn't automatically mean that there's a memory leak (as many seem to think). It does mean you have to be a little more aware of how circular references are created for IE4-6. Most of the addEvent scripts out there take memory leaks into account and will ensure that memory gets recaptured when the page unloads.

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.