On: JavaScript Programming Patterns

[monos]

easiest & most flexible is still this:

  var myNamespace = {};
  myNamespace.foo = function() {
      var privateFoo = 1;
      this.publicBar = "test";
      
      var privateFn = function() {};
      this.publicFn = function() {};
      return this;
  }

  // usage
  myFoo = new myNamespace.foo();

as crockford says & in my experience http://javascript.crockford.com/private.html

this also allows you to do prototypal inheritance, which is not possible with other "module patterns" - whatever that is, they are just singletons.

[aarongough → monos]

I agree. For small projects I use the same pattern but in the global namespace. I normally also create an intentional closure when initiating the object, this way I can refer to the parent object regardless of whether it's methods have been copied away or not (like when you assign an object method to an event handler)

  var testObject = function()
    {
    // Make sure the 'this' object is always available
    // to the object's methods via the 'thisObj' variable
    var thisObj = this;

    this.publicVar = "This is a string";

    this.alertBox = function()
      {
      alert( thisObj.publicVar );
      }
    }

  object1 = new testObject();

  window.onload = object1.alertBox

[monos → aarongough]

I know what you mean. When I have lots of event-handlers in a prototype I like to assign

  var self = this;

but that's bikeshedding

[aarongough → monos]

What do you mean by 'bikeshedding'?

[monos → aarongough]

http://catb.org/jargon/html/B/bikeshedding.html

wether we should call it thisObj or self :)

[aarongough → monos]

Ah gotcha. I checked the definition at a few places but the context still seemed unclear.

I agree, one way or the other is fine. Do you use 'self' because you're a Ruby coder? That actually the reason I would stay away from it! But then again I'm easily confused :-p

[yannis → monos]

Do you need the

    return this;