Pseudo-classical vs. “The JavaScript way”

Question

Just finished reading Crockford\'s \"JavaScript: The Good Parts\" and I have a question concerning his stance on the psuedo-classical vs. prototypal approaches.

Answer 1

Javascript isn't a person so she can't really suggest what you do.

None of the answers above have mentioned the plain-old functional style of inheritance, which I tend to find is the simplest.

function myModuleMaker(someProperty){
  var module = {}; //define your new instance manually

  module.property = someProperty; //set your properties

  module.methodOne = function(someExternalArgument){
    //do stuff to module.property, which you can, since you have closure scope access
  return module;
  }
}

Now to make a new instance:

var newModule = myModuleMaker(someProperty);

You still get all the benefits of pseudoclassical this way, but you suffer the one drawback that you're making a new copy of all your instance's methods every time you instantiate. This is probably only going to matter when you start having many hundreds (or indeed, thousands) of instances, which is a problem most people seldom run into. You're better off with pseudoclassical if you're creating truly enormous data structures or doing hard-core animations with many, many instances of something.

I think it's hard to argue that either method is "bad practice" per se.

Answer 2

Your implementation is problematic because you're replacing the entire prototype object, losing the properties of the inherited function prototype and it would also break, or at least make it more difficult, the ability to make use of inheritance later on if you wrote other classes the same way.

A method more suited to Javascript would be:

var MyClass = function (storeThis) {
 this.storage = storeThis
}

MyClass.prototype.getStorage = function (){
   return this.storage;
}

MyClass.prototype.setStorage = function (newStorage){
  this.storage = newStorage;
}

Use it:

var myInstance = new MyClass("sup");
alert("myInstance storage: " + myInstance.getStorage());
myInstance.setStroage("something else");

As for the 'new' keyword and Crawford's problems with it, I can't really answer, because I haven't read the book, but I can see how you could create a new object by calling any function with the new keyword, including functions that are supposed to be methods of a class.

And when someone says something, such as a design pattern, is more 'expressive', he or she generally means that the design pattern is clear and simple to understand as to what it is achieving and how.

Answer 3

See: Is JavaScript's “new” Keyword Considered Harmful?

It's important to remember that Crockford, like so many other JavaScript programmers, first approached the language with an eye toward "fixing" it - making it more like other (so-called "classical") OO languages. So a large amount of structural code was written, libraries and frameworks built, and... then they started to realize that it wasn't really necessary; if you approach JS on its own terms, you can get along just fine.

Answer 4

The prototypal variant for the example you have looks like the following in my understanding:

Object.beget = function (o) { /* Crockfords replacement for the new */ }

var myModule = {
    something : null,
    getSomething : function () {},
    setSomething : function () {},
    doSomething : function () {}
};

And then you can do:

var foo = Object.beget(myModule);
foo.something = bar;

UPDATE: You can also use the builder pattern to replace a constructor like this:

var myModuleBuilder = {
    buildMyModule : function (something) {
        var m = Object.beget(myModule);
        m.something = something || {};
        return m;
    }
}

so then you can do:

var foo = myModuleBuilder.buildMyModule(something);