Originally Posted by Airblader
But if you drop setting the prototype in favor of this, i.e. you do this:
ouch, i didn't say drop the prototype. we want to inherit both the Constructor's "own properties" using apply() and the prototype methods by duping, assigning, or otherwise binding the first prototype to the second Constructor.
nothing in the OPs code has to fundamentally change, it's a single call change that's compatible with everything else going in the OP's code.
if you don't assign the proto to a new object or use Object.create(), you'll end up modifying both prototypes at once.
in your third example, you in-explicitly create a Game.prototype.play(). that might be a good thing in some cases, but i don't think that's what the OP was going for...
in particular, the combo of apply()ing the constructors to each-other works well after using NetworkGame.prototype = new Game();
to inherit both the protos and owns of Game() on NetworkGame()... An issue with doing only the proto=new Instance routine that is that you turn own properties into inherited ones. that means that if Game() defined this.eventPool=, each NetworkGame instance would use the exact same event pool array, which could cause problems. By apply()ing the Game to NetworkGame, you create a uniqe eventPool property on every instance, shadowing out the NetworkGame.prototype.eventPool that was created using NetworkGame.prototype=new Game() step.
in short, the one-two punch of assigning the new constructor's prototype to a new instance of the old and applying the old constructor to the instance of the new is the closest thing to Java-style inheritance of owns and deriveds without resorting to looping or fancy tricks.