We Keep Coding

Javascript nested prototypes

The other day I was fiddling with Javascript, and I noticed that I can't write a prototype to an object within a prototype function. Like this:
var obj = function() { }
obj.prototype.First = function() {
this.prototype.Second = function() {
alert("Second Prototype");
}
}
obj.First();
obj.Second();
For some reason, the second prototype won't work and the code doesn't run. Is my syntax wrong or are there some prototype limitations that I don't know about? Thanks!
Edit:
I'm not trying to add a prototype to a prototype... that wouldn't make much sense. This is what I'm trying to do: Add two separate prototypes to obj. Prototype 2 is defined when prototype 1 is called. I thought that this would contain a reference to object, so this.prototype would be the same as obj.prototype, but it doesn't work as expected.

This is an old question, but I thought I'd add my two cents.
This code is trying to add functions on 'prototype'. However, this can only be done on the class name. What you have is a variable pointing to an anonymous class. To access the variable of an anonymous variable use 'proto'. The below is the same as your example, except, using proto it is 'successful'. Although, I don't see the benefit of using prototypes like this as the prototype added methods only apply to the anonymous instance 'obj'. http://jsbin.com/zapocamipi/edit?js,console
var obj = function() { }
obj.__proto__.First = function() {
console.log("First Prototype");
this.__proto__.Second = function() {
console.log(this);
}
}
obj.First();
obj.Second();

Maybe this could help you out understanding the role of a constructor function and the prototype.
Depending on what you're trying to do (obj, First and Second doesn't really show your intention) you could do:
A Person has Eyes. This can be done through composition.
An Employer is a Person but a Person is not necessarily an Employer (can be Client or Consultant too). This could be done through inheritance.
A Cat can move. In a Class based language Cat has to implement Movable but in JavaScript you can use mix ins and leave the implementation to the default implementation that Movable provides or override it. JavaScript does not compile time check if you do implement certain things.
If you would like to change the type of the object instance after calling a certain function then it's dangerous to meddle with the prototype because that will affect all instances of that type.
Maybe you should return an instance of another type.
var Customer = function(name) {
this.name=name || 'unknown';
};
Customer.createVipCustomer = function() {
return new VipCustomer(this);
}
var VipCustomer=function(customer){
//re use Customer constructor
Customer.call(this,customer.name);
this.isVip=true;
}
//inherit the protype defined members
VipCustomer.prototype=Object.create(Customer.prototype);
VipCustomer.prototype.constructor=VipCustomer;
VipCustomer.prototype.second=function(){
console.log('this is second');
}
var aCustomer = new Customer('Ben');
//update to VipCustomer
aCustomer = Customer.createVipCustomer(aCustomer);
aCustomer.second();

this.prototype doesn't exist.
If you want to add a property to the instance, use this.
If you want to add a property to the prototype, use Constructor.prototype.
Also, obj is a function (class), not an instance,
You want to create an instance using the new keyword, and you should name the constructor function as UpperCamelCase.

Confusion over Classical and Prototypal Inheritance Javascript

// Prototye Inheritance
var AnswerPrototype = {
constructor: function(value){
this._val = value;
},
get: function(){
return this._val;
}
}
var lifeAnswer = Object.create(AnswerPrototype);
lifeAnswer.constructor(100);
alert(lifeAnswer.get());
var desertAnswer = Object.create(AnswerPrototype);
desertAnswer.constructor(200);
alert(desertAnswer.get());
var firmAnswerProtoype = Object.create(AnswerPrototype);
firmAnswerProtoype.get = function(){
return AnswerPrototype.get.call(this);
}
var luckyAnswer = Object.create(firmAnswerProtoype);
luckyAnswer.constructor(1);
alert(luckyAnswer.get());
var magicAnswer = Object.create(firmAnswerProtoype);
magicAnswer.constructor(2);
alert(magicAnswer.get());
// Classical Inheritance
function Answer(value){
this._val = value;
}
Answer.prototype.get = function(){
return this._val;
}
var lifeAnswer = new Answer(100);
alert(lifeAnswer.get());
var desertAnswer = new Answer(200);
alert(desertAnswer.get());
function firmAnswer(value){
return Answer.call(this,value);
}
firmAnswer.prototype = Object.create(Answer);
firmAnswer.prototype.constructor = firmAnswer;
firmAnswer.prototype.get = function(){
return Answer.prototype.get.call(this);
}
var luckyAnswer = new firmAnswer(20);
alert(luckyAnswer.get())
Can anyone tell me on how the second one is classical and the first one is prototypal. I was watching the http://www.objectplayground.com/ and i am totally confused as in both the cases we use Object.create() and as well as prototype object.

First, to get it straight, Javascript only has prototypal inheritance. What you can do is simulate "classical" inheritance. The difference between the two boils down to the syntax with which objects are instantiated - "classical" inheritance uses the more familiar constructor functions and "new" operator, which hide the inherent prototypal nature of Javascript's object creation and inheritance properties.
Let's break down both cases a bit.
var AnswerPrototype = {
constructor: function(value){
this._val = value;
},
get: function(){
return this._val;
}
}
The prototype here is explicitly created, along with a "constructor" (or more properly named, initializing function).
var lifeAnswer = Object.create(AnswerPrototype);
lifeAnswer.constructor(100);
alert(lifeAnswer.get());
Now, creating objects is slightly clunky here. First you need to call Object.create(), and then you need to call the initializer function. This doesn't have to be the case though - here's a different sample prototype which does both in one swoop:
var AnswerPrototype = {
create: function(value){
var obj = Object.create(AnswerPrototype);
obj._val = value;
return obj;
},
get: function(){
return this._val;
}
}
var lifeAnswer = AnswerPrototype.create(100);
Simulating "classical" inheritance relies on letting developers use the more familiar constructor functions and "new" operator to create their objects, but since it it just masking the prototypal inheritance of Javascript, it remains essentially the same thing.
function Answer(value){
this._val = value;
}
Answer.prototype.get = function(){
return this._val;
}
This isn't much different from the prototypal inheritance one, except the Answer is decoupled from the now implicitly created prototype object(Which can be accessed via the Answer.prototype property)
var lifeAnswer = new Answer(100);
Practically, sugar for var lifeAnswer = Object.create(Answer.prototype); // Call Answer on the newly created object to initialize some values, e.g. with Answer.call(lifeAnswer, 100);
firmAnswer.prototype = Object.create(Answer);
firmAnswer.prototype.constructor = firmAnswer;
firmAnswer.prototype is just the implicitly created prototype, very similar to firmAnswerPrototype in the first case.
To answer your specific question, the reason why they use Object.create() here is because inheritance via new quickly becomes very clunky. You would need to do something like:
firmAnswer.prototype = new Answer();
But now you either need Answer to be an empty constructor(function Answer() {}), or explicitly differentiate between calling it with no arguments(to use for inheritance), and calling it with arguments(to use for instantiating "Answer" objects).

You have those backwards. The second one is prototypal because it uses the object's prototype property to inherit. This block
firmAnswer.prototype = Object.create(Answer);
firmAnswer.prototype.constructor = firmAnswer;
firmAnswer.prototype.get = function(){
return Answer.prototype.get.call(this);
}
is assigning an instance of Answer to firmAnswer's prototype. However, it's piss poor code, as it's not actually taking advantage of the inheritance, it's redeclaring the get function.
I would avoid this code altogether. Read Crockford's The Good Parts for a good distinction between the two types.
EDIT: To give a bit of an explanation (without referencing that code), here's the basic difference.
'Classical' inheritance in Javascript (the way I see it used) is when you override objects properties. You have an object with a foo and a bar method. You then use a library (like jQuery or Prototype) to call an extend method. The method takes two arguments, a base object and a child object. It takes all of the properties of the base object, inserts the properties of the child object (possibly overwriting) and then returns a new object that has a mix of both properties. There's a bit more to it, but that's the gist. It's just manipulating object properties without the prototype.
Prototypal inheritance uses Javascript's built in prototype. A prototype is a chain of objects (essentially). Let's say you have an object B that inherits from A. To create a C class that inherits from B, we create a function named C and then assign B to the prototype. Then, when a property is requested from C, Javascript will do the following:
Check if the property exists on the instance of C. If not:
Check if the property is on the prototype of B. If not:
Check if the property is on the prototype of A. If not:
Throw error.
Sorry if it's a little vague. I'm trying to simplify it a bit. There's a lot to the prototype in Javascript. I would suggest reading some of Crockford's materials.

How is the second one is classical and the first one is prototypal
Both are using prototypical inheritance, there are no classes in JavaScript.
The second one is called "classical" (sometimes "pseudoclassical") because it uses the class pattern and mimics the conventional class syntax (as known from Java) when objects are created with the new operator.
The only difference is the .prototype link from the constructor function to the prototype object and the shorter instantiation syntax with only one command instead of two, what happens behind is the same in both approaches.
As we can see in your example, also the inheritance between two "classes" is a bit different. In both approaches the child prototype object inherits from the parent prototype object, and in both approaches you can call parent ("super") methods by invoking the functions explicitly on the child instance. Yet, in the "classical" pattern you need to declare a new constructor function for the child (to reference it), while in your explicit prototypical approach the children are inheriting the parent's .constructor method.

A few questions about how JavaScript works

I have been looking deeply into JavaScript lately to fully understand the language and have a few nagging questions that I can not seem to find answers to (Specifically dealing with Object Oriented programming).
Assuming the following code:
function TestObject()
{
this.fA = function()
{
// do stuff
}
this.fB = testB;
function testB()
{
// do stuff
}
}
TestObject.prototype = {
fC : function
{
// do stuff
}
}
What is the difference between functions fA and fB? Do they behave exactly the same in scope and potential ability? Is it just convention or is one way technically better or proper?
If there is only ever going to be one instance of an object at any given time, would adding a function to the prototype such as fC even be worthwhile? Is there any benefit to doing so? Is the prototype only really useful when dealing with many instances of an object or inheritance?
And what is technically the "proper" way to add methods to the prototype the way I have above or calling TestObject.prototype.functionName = function(){} every time?
I am looking to keep my JavaScript code as clean and readable as possible but am also very interested in what the proper conventions for Objects are in the language. I come from a Java and PHP background and am trying to not make any assumptions about how JavaScript works since I know it is very different being prototype based.

What is the difference between functions fA and fB
In practice, nothing. The primary difference between a function expression (fA) and a function declaration (fB) is when the function is created (declared functions are available before any code is executed, whereas a function expression isn't available until the expression is actually executed). There are also various quirks associated with function expressions that you may stumble across.
In the example, I'd use a function expression, simply because declaring a function expression, then assigning the result seems a bit abstracted. But there is nothing "right" or "wrong" about either approach.
If there is only ever going to be one instance of an object at any given time, would adding a function to the prototype such as fC even be worthwhile?
No. Just about everyone who goes does inheritance finds that plain objects are often simpler and therefore "better". Prototype inheritance is very handy for patching built–in objects though (e.g. adding Array.prototype.each where absent).
And what is technically the "proper" way to add methods to the prototype…
There isn't one. Replacing the default prototype with some other object seems like a bit of a waste, but assigning an object created by a literal is perhaps tidier and easier to read that sequential assignments. For one or two assignments, I'd use:
Constructor.prototype.method = function(){…}
but for lots of methods I'd use an object literal. Some even use a classic extend function and do:
myLib.extend(Constructor.prototype, {
method: function(){…}
});
Which is good for adding methods if some have already been defined.
Have a look at some libraries and decide what you like, some mix and match. Do whatever suits a particular circumstance, often it's simply a matter of getting enough code to all look the same, then it will look neat whatever pattern you've chosen.

fA and fB are effectively the same and it is just a matter of convention.
If there is only one instance of a object I wouldn't even use a constructor function, but rather just a object literal, such as:
var o = {
fA: function () { ... },
fB: function () { ... },
fC: function () { ... }
};
As for adding it to an instance or a prototype, the instance is slightly more efficient than adding it to the prototype if you only have one instance but, as I said, use a literal instead.
I avoid declaring functions in the constructor because each invocation of the constructor will create new object representing each function. These objects are not very large they tend to add up if many objects are created. If the functions can be moved to the prototype, it is much more efficient to do so.
As for adding to the prototype, I favor the
TestObject.prototype.functionName = function () { };
style but it is a matter of preference. I like the above because it looks the same whether you are extending the prototype or creating the intial prototype.

Also are there any definitive JavaScript style guides or documentation
about how JavaScript operates at a low level?
Damn no javascript programmer should ever miss "Professional JavaScript for Web Developers". This is a fantastic book, that goes into the deep. It explains objects, class emulation, functions, scopes and much much more. It is also a JS reference.
And what is technically the "proper" way to add methods to the
prototype the way I have above or calling
TestObject.prototype.functionName = function(){} every time?
As for the way to define classes, I would recommend to have a look at various JS MVC frameworks (like Spine.js, which is lightweight ). You do not need the whole of them, just their class emulation libraries. The main reason for this, is that JS does not have the concept of classes, rather it is purely consisted of objects and prototypes. On the other hand classes can be perfectly emulated (please do not take the word emulated as it is something missing). As this needs some discipline from the programmer, it is better to have a class emulation library to do the job and make you code cleaner.
The standard methods that a programmer should expect of a class emulation library are:
// define a new Class
var AClass = Class.create({
// Object members (aka prototype),
// usually an initialize() method is called if it is defined
// as the "constructor" function when a class object is created
}, {
// Static members
});
// create a child class that inherits methods and attributes from parent
var ChildClass = AClass.extend({
// Child object members
},{
// Child static members
});
AClass.include({
// Object amendments (aka mixin), methods and attributes
// to be injected to the class object
},{
// Statics amendments, methods and attributes to be
// injected as class static members
});
// check object type
var aObj = new AClass();
aObj instanceof AClass; // true
aObj instanceof ChildClass; // false
var cObj = new ChildClass();
cObj instanceof AClass; // true
cObj instanceof ChildClass; // true

I answer for first part: there is no differences, when you declare function not as variable then declaration of it rises in the block, so
...
func();
...
function func () { ... }
is equal to
var func = function () { ... };
...
func();
...
So your code
function TestObject () {
this.fA = function() { // do stuff };
this.fB = testB;
function testB() { // do stuff }
}
is equal to
function TestObject () {
var testB = function () { // do stuff };
this.fA = function () { // do stuff };
this.fB = testB;
}

Prototypal Inheritance best practices?

I'm just getting into JavaScript and I'm trying to wrap my head around prototypal inheritance. It appears that there's multiple ways to achieve the same effect, so I wanted to see if there is any best practices or reasons to do things one way over the other. Here's what I'm talking about:
// Method 1
function Rabbit() {
this.name = "Hoppy";
this.hop = function() {
console.log("I am hopping!");
}
}
// Method 2
function Rabbit() {}
Rabbit.prototype = {
name: "Hoppy",
hop: function() {
console.log("I am hopping!");
}
}
// Method 3
function Rabbit() {
this.name = "Hoppy";
}
Rabbit.prototype.hop = function() {
console.log("I am hopping!");
}
// Testing code (each method tested with others commented out)
var rabbit = new Rabbit();
console.log("rabbit.name = " + rabbit.name);
rabbit.hop();
All of these appear to have the same effect individually (unless I'm missing something). So is one method preferred over the other? How do you do it?

When you put a method on the prototype, every instance object shares the same reference to the method. If you have 10 instances, there is 1 copy of the method.
When you do what you did in example 1, every instance object has its own version of the same method, so if you create 10 of your objects, there are 10 copies of the code running around.
Using the prototype works because javascript has machinery for associated a function execution with a instance, i.e. it sets the this property for the execution of the function.
So using the prototype is highly preferred since it uses less space (unless of course, that is what you want).
In method 2, you are setting the prototype by setting it equal to an object literal. Note that here you are setting a property, which I think you don't intend to do, since all instances will get the same property.
In Method 3, you are building the prototype one assignment at a time.
I prefer method 3 for all things. i.e. In my constructor I set my property values
myObj = function(p1){
this.p1; // every instance will probably have its own value anyway.
}
myObj.prototype.method1 = function(){..} // all instances share the same method, but when invoked **this** has the right scope.

Let's look at your examples one at a time. First:
function Rabbit() {
this.name = "Hoppy";
this.hop = function() { //Every instance gets a copy of this method...
console.log("I am hopping!");
}
}
var rabbit = new Rabbit();
The above code will work, as you have said in your question. It will create a new instance of the Rabbit class. Every time you create an instance, a copy of the hop method will be stored in memory for that instance.
The second example looked like this:
function Rabbit() {}
Rabbit.prototype = {
name: "Hoppy",
hop: function() { //Now every instance shares this method :)
console.log("I am hopping!");
}
}
var rabbit = new Rabbit();
This time, every instance of Rabbit will share a copy of the hop method. That's much better as it uses less memory. However, every Rabbit will have the same name (assuming you don't shadow the name property in the constructor). This is because the method is inherited from the prototype. In JavaScript, when you try to access a property of an object, that property will first be searched for on the object itself. If it's not found there, we look at the prototype (and so on, up the prototype chain until we reach an object whose prototype property is null).
Your third example is pretty much the way I would do it. Methods shared between instances should be declared on the prototype. Properties like name, which you may well want to set in the constructor, can be declared on a per-instance basis:
function Rabbit(rabbitName) {
this.name = rabbitName;
}
Rabbit.prototype.hop = function() {
console.log("Hopping!");
}

This is an important issue that is often misunderstood. It depends what you're trying to do. Generally speaking, hvgotcode's answer is right on. Any object that will be instantiated frequently should attach methods and properties to the prototype.
But there are advantages to the others in very specific situations. Read this, including the comments: http://net.tutsplus.com/tutorials/javascript-ajax/stop-nesting-functions-but-not-all-of-them/
There are occasions when method 1 above helps, enabling you to have "private" readable/writable properties and methods. While this often isn't worth the sacrifice in heavily instantiated objects, for objects instantiated only once or a few times, or without many internal assignments, or if you're in a dev team environment with lots of different skill levels and sensibilities, it can be helpful.
Some devs incorporate another good strategy that attempts to bridge some of the shortcomings of the others. That is:
var Obj = function() {
var private_read_only = 'value';
return {
method1: function() {},
method2: function() {}
};
};

// option 4
var Rabbit {
constructor: function () {
this.name = "Hoppy";
return this;
},
hop: function() {
console.log("I am hopping!");
}
};
var rabbit = Object.create(Rabbit).constructor();
console.log("rabbit.name = " + rabbit.name);
rabbit.hop();
When doing prototypical OO using new and constructor functions is completely optional.
As has already been noted, if you can share something through the prototype do so. Prototypes are more efficient memory wise and they are cheaper in terms of instantiation time.
However a perfectly valid alternative would be
function Rabbit() {
// for some value of extend https://gist.github.com/1441105
var r = extend({}, Rabbit);
r.name = "Hoppy";
return r;
}
Here your extending "instances" with the properties of the "prototype". The only advantage real prototypical OO has is that it's a live link, meaning that changes to the prototype reflect to all instances.

Do some performance testing (declare around 1 milion rabbit variables) . First method will be the most time and memory consuming.

Javascript Inheritance and Arrays

I am trying to define a javascript class with an array property, and its subclass. The problem is that all instances of the subclass somehow "share" the array property:
// class Test
function Test() {
this.array = [];
this.number = 0;
}
Test.prototype.push = function() {
this.array.push('hello');
this.number = 100;
}
// class Test2 : Test
function Test2() {
}
Test2.prototype = new Test();
var a = new Test2();
a.push(); // push 'hello' into a.array
var b = new Test2();
alert(b.number); // b.number is 0 - that's OK
alert(b.array); // but b.array is containing 'hello' instead of being empty. why?
As you can see I don't have this problem with primitive data types... Any suggestions?

Wen you write Test2.prototype = new Test(), you create a single Test instance, with a single array instance, which is shared by every Test2 instance.
Therefore, all of the Test2 instances are sharing the same array.
You can solve this problem by calling the base Test constructor from the Test2 constructor, which will create a new array instance for every Test2 instance.
For example:
function Test2() {
Test.call(this);
}

Another, rather inelegant, alternative is to move initialization code from the constructor to a method and call it from both constructors:
// class Test
function Test() {
this.init();
}
Test.prototype.init = function() {
this.array = [];
this.number = 0;
};
Test.prototype.push = function() {
this.array.push('hello');
this.number = 100;
};
// class Test2 : Test
function Test2() {
this.init();
}
Test2.prototype = new Test();

Only thing I can think of is that arrays are shared references. There should be an obvious solution since this kind of classic OOP code is implemented all the time in Javascript.

JavaScript does not have a classical inheritance system, it has a prototypical inheritance system. So in JavaScript technically there is no concept of "Class".
Objects inherit from other objects (the so called prototype object), not abstract classes. One big consequence of this is that if several objects share the same prototype and one of these objects change an attribute defined in the prototype, that change is effective immediately to all other objects.
Trying to use JavaScript inheritance as if it was based on classes usually causes big headaches, because you find this type of problems all the time.
I know this does not really answer your particular questions, but at a high level I recommend you embrace the prototypical inheritance instead of trying to use "pseudo-classes". Even if it looks weird at first, your code will be much more reliable and you will not lose time trying to understand strange bugs like this, cause by a strange chain of prototypes.
Watch this video where Douglas Crockford explains inheritance, it's available online in Yahoo UI Theater website. It changed the way I programmed in JavaScript :)
http://video.yahoo.com/watch/111585/1027823 (link to the first part)
http://developer.yahoo.com/yui/theater/ (for all the videos)