JS class pattern [2]

klass2.js

// AMD module definition:
define(function (require) {

  // An instantiable class:
  var K = function () {
    this._initialize();
    this._p = {};
  };
  
  
  // A "private" method:
  K.prototype._initialize = function () {
  }


  // A public method:
  K.prototype.update = function () {
  }


  // A constant
  K.MEANING_OF_LIFE = 42;
  
  return K;

});

Well, it is var thing = new Thing() in both cases — that's important. I find that I and P become second nature very quickly — that was definitely true for API and k and p in the old pattern.

I agree that tinkering with private methods in console or via inheritance is great — rarely have we needed truly private methods, and anyway, we have those if we're prepared to pass instance data in as an argument. The "protected" implication of underscore-prefixed methods is reasonably nice (well, gallingly ugly, but nice).

I must admit I don't like your shorthand version because that trailing comma is always a bitch, and especially when you have liberally applied comments to your codebase. Also it's another level of indentation (which is another problem with the first proposal too). And if you are inheriting, you can't use the shorthand, so it's better to have one rule.

I think we can more or less blacklist super — super-free inheritance is still better than our current no-inheritance. If we write small, focused methods it's not a big deal.

Alright, you've swayed me. I'm going to reimplement the Stencil (which is totally changing in the Monocle->Lens transition) in this style then review it.

Also, you want to read this for getting AMD requires working in a CommonJS way reliably: http://requirejs.org/docs/whyamd.html#sugar

Oh, I had a confusing typo from my console experiments — see https://gist.github.com/joseph/9766958/revisions. The 'foo' did not belong, it was for testing only.