I have not been able to find an answer to this. Objects in JavaScript have an inheritance chain; the chain of any function is Function => Object, the chain of an instance of TypeError is TypeError => Error => Object, and the chain of TypeError is, oddly, Function => Function => Object.
I had looked up how to make a constructed object inherit properties from another function in addition to its direct constructor, expecting the resulting inheritance chain to be object => constructor => second function and for this to be how one constructor would extend another. The solution that I had found was to call <second function>.<call or apply>(this[, optional arguments...]) inside the body of the constructor, but object instanceof <second function> ended up returning false.
Further research revealed mostly answers that use class syntax or Object.create, but those are new and one "class" extending another in JavaScript has been around since the creation of the language, so there's some other way that's used to do this. This information is something that should be mentioned right alongside basic explanations of JavaScript constructors yet it is not. What is the primary method of extending a "class" (not actual class syntax) resulting in deeper inheritance chains?
Example result:
// Square is the subclass
// Rectangle is the superclass
var rectangle = new Rectangle(1, 1);
var square = new Square(1);
rectangle instanceof Rectangle; // true
rectangle instanceof Square; // false
square instanceof Rectangle; // true
square instanceof Square; // true
Square instanceof Rectangle; // true
False solution:
function F () {
this.value = 0;
}
function G () {
F.apply(this);
}
var f = new F();
var g = new G();
// g gets the same properties from F that f gets.
"value" in f; // true
"value" in g; // true
// But neither g nor G are instances of F.
g instanceof G; // true
g instanceof F; // false
G instanceof F; // false
one "class" extending another in JavaScript has been around since the creation of the language
No, it hasn't. JavaScript was never (and still is not) a class-based language. The only tools you had were .prototype and new.
How were "classes" extended prior to Object.create?
Using the same approach, basically. The key to setup the prototype chain is
Subclass.prototype = Object.create(Superclass.prototype);
and without Object.create, people just created that object using
Subclass.prototype = new Superclass;
See the answers from 2010 in How to inherit from a class in javascript? for examples.
Yes, this is a bad idea, but it proliferated. Better solutions that would not execute the superclass constructor were devised, and this is how Object.create came into existence, popularised by Douglas Crockford (see also What is happening in Crockford's object creation technique?).
So I thought that I'd include a couple of examples of "extensions" in javascript from my old project just in case that is what was being looked for.
Here's an example of "extending" all objects by modifying the valueOf function. First it copies the built-in .valueOf definition to a new function/property -> .originalvalueOf, then adds my custom .valueOf over the built-in one. I did this so that JS numbers would throw an error for things like NaN or division by zero. As you can see it is done by modifying the Object.prototype, and my new .valueOf actually calls the built-in version through .originalvalueOf.
/* **** Object extensions ****
Check for NaN and DivZeros
(adapted from: https://stackoverflow.com/a/20535480/109122)
*/
Object.prototype.originalValueOf = Object.prototype.valueOf;
Object.prototype.valueOf = function() {
if (typeof this == 'number') {
if (!isFinite(this)) {throw new Error('Number is NaN or not Finite! (RBY)');}
}
return this.originalValueOf();
}
// var a = 1 + 2; // -> works
// console.log(a); // -> 3
// var b = {};
// var c = b + 2; // -> will throw an Error
Here's an example of a constructor for my "class" called Pe2dSpatialState. Note that I've added all of the object's fields here:
// Constructor for Dynamic Spatial State
//( physical properties that change according to Newtonian Mechanics )
var Pe2dSpatialState = function(point2dPosition,
point2dVelocity,
point2dAcceleration,
interval,
rotationDegrees,
rotationDegreesPerSec) {
this.position = point2dPosition; // position of this state
this.velocity = point2dVelocity; // velocity of this state
this.acceleration = point2dAcceleration; // acceleration to be applied
this.interval = interval; // time to the next state
this.rotationD = (rotationDegrees ? rotationDegrees : 0);
// degrees rotated (because SVG uses degrees)
this.rotationDPerSec = (rotationDegreesPerSec ? rotationDegreesPerSec : 0);
// degrees per sec (because SVG uses degrees)
}
I added functions to Pe2dSpatialState objects through the prototype:
Pe2dSpatialState.prototype.clone = function() {
var tmp = new Pe2dSpatialState( this.position.clone(),
this.velocity.clone(),
(this.acceleration ? this.acceleration.clone() : undefined),
this.interval,
this.rotationD,
this.rotationDPerSec);
return tmp;
}
Then I added get/set type "properties" using Object.defineProperty:
Object.defineProperty(Pe2dSpatialState.prototype, "rotationR", {
get() {return this.rotationD * Math.PI * 2 / 360;},
set(v) {this.rotationD = v * 360 / (Math.PI * 2);}
});
Object.defineProperty(Pe2dSpatialState.prototype, "rotations", {
get() {return this.rotationD / 360;},
set(v) {this.rotationD = v * 360;}
});
Checking my listings, I always defined my "classes" in this order: Constructor function with fields, then adding functions/methods to the prototype and finally adding properties with Object.defineProperty. And only after that would I use it anywhere.
I cannot remember exactly why I did everything in these three different ways, except that I went through a lot of different attempts and iterations and this is what I finally landed on as working for me. (This is all probably much easier under ES6).
I also found a very sophisticated function that would list out the object-function-prototype trees for any object that was hugely helpful to me in figuring out what was really happening and what would work. I haven't included it because it's long, but if you want to see it then I will post it here.
(I cannot guarantee that this is the best way to do this nor even that there aren't any mistakes in this code. In fact, looking at it now, I suspect that some of my fields should have been properties instead...)
Does Kyle Simpson's "OLOO (Objects Linking to Other Objects) Pattern" differ in any way from the the Prototype design pattern? Other than coining it by something that specifically indicates "linking" (the behavior of prototypes) and clarifying that there's no to "copying" happening here (a behavior of classes), what exactly does his pattern introduce?
Here's an example of Kyle's pattern from his book, "You Don't Know JS: this & Object Prototypes":
var Foo = {
init: function(who) {
this.me = who;
},
identify: function() {
return "I am " + this.me;
}
};
var Bar = Object.create(Foo);
Bar.speak = function() {
alert("Hello, " + this.identify() + ".");
};
var b1 = Object.create(Bar);
b1.init("b1");
var b2 = Object.create(Bar);
b2.init("b2");
b1.speak(); // alerts: "Hello, I am b1."
b2.speak(); // alerts: "Hello, I am b2."
what exactly does his pattern introduce?
OLOO embraces the prototype chain as-is, without needing to layer on other (IMO confusing) semantics to get the linkage.
So, these two snippets have the EXACT same outcome, but get there differently.
Constructor Form:
function Foo() {}
Foo.prototype.y = 11;
function Bar() {}
Bar.prototype = Object.create(Foo.prototype);
Bar.prototype.z = 31;
var x = new Bar();
x.y + x.z; // 42
OLOO Form:
var FooObj = { y: 11 };
var BarObj = Object.create(FooObj);
BarObj.z = 31;
var x = Object.create(BarObj);
x.y + x.z; // 42
In both snippets, an x object is [[Prototype]]-linked to an object (Bar.prototype or BarObj), which in turn is linked to third object (Foo.prototype or FooObj).
The relationships and delegation are identical between the snippets. The memory usage is identical between the snippets. The ability to create many "children" (aka, many objects like x1 through x1000, etc) is identical between the snippets. The performance of the delegation (x.y and x.z) is identical between the snippets. The object creation performance is slower with OLOO, but sanity checking that reveals that the slower performance is really not an issue.
What I argue OLOO offers is that it's much simpler to just express the objects and directly link them, than to indirectly link them through the constructor/new mechanisms. The latter pretends to be about classes but really is just a terrible syntax for expressing delegation (side note: so is ES6 class syntax!).
OLOO is just cutting out the middle-man.
Here's another comparison of class vs OLOO.
I read Kyle's book, and I found it really informative, particularly the detail about how this is bound.
Pros:
For me, there a couple of big pros of OLOO:
1. Simplicity
OLOO relies on Object.create() to create a new object which is [[prototype]]-linked to another object. You don't have to understand that functions have a prototype property or worry about any of the potential related pitfalls that come from its modification.
2. Cleaner syntax
This is arguable, but I feel the OLOO syntax is (in many cases) neater and more concise than the 'standard' javascript approach, particularly when it comes to polymorphism (super-style calls).
Cons:
I think there is one questionable bit of design (one that actually contributes to point 2 above), and that is to do with shadowing:
In behaviour delegation, we avoid if at all possible naming things the same at different levels of the [[Prototype]] chain.
The idea behind this is that objects have their own more specific functions which then internally delegate to functions lower down the chain. For example, you might have a resource object with a save() function on it which sends a JSON version of the object to the server, but you may also have a clientResource object which has a stripAndSave() function, which first removes properties that shouldn't be sent to the server.
The potential problem is: if someone else comes along and decides to make a specialResource object, not fully aware of the whole prototype chain, they might reasonably* decide to save a timestamp for the last save under a property called save, which shadows the base save() functionality on the resource object two links down the prototype chain:
var resource = {
save: function () {
console.log('Saving');
}
};
var clientResource = Object.create(resource);
clientResource.stripAndSave = function () {
// Do something else, then delegate
console.log('Stripping unwanted properties');
this.save();
};
var specialResource = Object.create( clientResource );
specialResource.timeStampedSave = function () {
// Set the timestamp of the last save
this.save = Date.now();
this.stripAndSave();
};
a = Object.create(clientResource);
b = Object.create(specialResource);
a.stripAndSave(); // "Stripping unwanted properties" & "Saving".
b.timeStampedSave(); // Error!
This is a particularly contrived example, but the point is that specifically not shadowing other properties can lead to some awkward situations and heavy use of a thesaurus!
Perhaps a better illustration of this would be an init method - particularly poignant as OOLO sidesteps constructor type functions. Since every related object will likely need such a function, it may be a tedious exercise to name them appropriately, and the uniqueness may make it difficult to remember which to use.
*Actually it's not particularly reasonable (lastSaved would be much better, but it's just an example.)
The discussion in "You Don't Know JS: this & Object Prototypes" and the presentation of the OLOO is thought-provoking and I have learned a ton going through the book. The merits of the OLOO pattern are well-described in the other answers; however, I have the following pet complaints with it (or am missing something that prevents me from applying it effectively):
1
When a "class" "inherits" another "class" in the classical pattern, the two function can be declared similar syntax ("function declaration" or "function statement"):
function Point(x,y) {
this.x = x;
this.y = y;
};
function Point3D(x,y,z) {
Point.call(this, x,y);
this.z = z;
};
Point3D.prototype = Object.create(Point.prototype);
In contrast, in the OLOO pattern, different syntactical forms used to define the base and the derived objects:
var Point = {
init : function(x,y) {
this.x = x;
this.y = y;
}
};
var Point3D = Object.create(Point);
Point3D.init = function(x,y,z) {
Point.init.call(this, x, y);
this.z = z;
};
As you can see in the example above the base object can be defined using object literal notation, whereas the same notation can't be used for the derived object. This asymmetry bugs me.
2
In the OLOO pattern, creating an object is two steps:
call Object.create
call some custom, non standard method to initialize the object (which you have to remember since it may vary from one object to the next):
var p2a = Object.create(Point);
p2a.init(1,1);
In contrast, in the Prototype pattern you use the standard operator new:
var p2a = new Point(1,1);
3
In the classical pattern I can create "static" utility functions that don't apply directly to an "instant" by assigning them directly to the "class" function (as opposed to its .prototype). E.g. like function square in the below code:
Point.square = function(x) {return x*x;};
Point.prototype.length = function() {
return Math.sqrt(Point.square(this.x)+Point.square(this.y));
};
In contrast, in the OLOO pattern any "static" functions are available (via the [[prototype]] chain) on the object instances too:
var Point = {
init : function(x,y) {
this.x = x;
this.y = y;
},
square: function(x) {return x*x;},
length: function() {return Math.sqrt(Point.square(this.x)+Point.square(this.y));}
};
"I figured to do it makes each obj dependent on the other"
As Kyle explains when two objects are [[Prototype]] linked, they aren't really
dependent on each other; instead they are individual object. You're linking one
object to the other with a [[Prototype]] linkage which you can change anytime you wish. If you take two [[Prototype]] linked objects created through OLOO style as being dependent on each other, you should also think the same about the ones created through constructor calls.
var foo= {},
bar= Object.create(foo),
baz= Object.create(bar);
console.log(Object.getPrototypeOf(foo)) //Object.prototype
console.log(Object.getPrototypeOf(bar)) //foo
console.log(Object.getPrototypeOf(baz)) //bar
Now think for a second do you think of foo bar and baz as being dependent on each-other?
Now let's do the same this constructor style code-
function Foo() {}
function Bar() {}
function Baz() {}
Bar.prototype= Object.create(Foo);
Baz.prototype= Object.create(Bar);
var foo= new Foo(),
bar= new Bar().
baz= new Baz();
console.log(Object.getPrototypeOf(foo)) //Foo.prototype
console.log(Object.getPrototypeOf(Foo.prototype)) //Object.prototype
console.log(Object.getPrototypeOf(bar)) //Bar.prototype
console.log(Object.getPrototypeOf(Bar.prototype)) //Foo.prototype
console.log(Object.getPrototypeOf(baz)) //Baz.prototype
console.log(Object.getPrototypeOf(Baz.prototype)) //Bar.prototype
The only difference b/w the latter and the former code is that in the latter one
foo, bar, baz bbjects are linked to each-other through arbitrary objects
of their constructor function (Foo.prototype, Bar.prototype, Baz.prototype) but in the former one (OLOO style) they are linked directly. Both ways you're just linking foo, bar, baz with each other, directly in the former one and indirectly in the latter one. But, in both the cases the objects are independent of each-other because it isn't really like an instance of any class which once instantiated, can't be made to inherit from some other class. You can always change which object an object should delegate too.
var anotherObj= {};
Object.setPrototypeOf(foo, anotherObj);
So they're all independent of each-other.
" I was hoping OLOO would solve the issue in which each object knows
nothing about the other."
Yes that's indeed possible-
Let's use Tech as an utility object-
var Tech= {
tag: "technology",
setName= function(name) {
this.name= name;
}
}
create as many objects as you wish linked to Tech-
var html= Object.create(Tech),
css= Object.create(Tech),
js= Object.create(Tech);
Some checking (avoiding console.log)-
html.isPrototypeOf(css); //false
html.isPrototypeOf(js); //false
css.isPrototypeOf(html); //false
css.isPrototypeOf(js); //false
js.isPrototypeOf(html); //false
js.isPrototypwOf(css); //false
Tech.isPrototypeOf(html); //true
Tech.isPrototypeOf(css); //true
Tech.isPrototypeOf(js); //true
Do you think html, css, js objects are connected to each-other? No, they aren't. Now let's see how we could've done that with constructor function-
function Tech() { }
Tech.prototype.tag= "technology";
Tech.prototype.setName= function(name) {
this.name= name;
}
create as many objects as you wish linked to Tech.proptotype-
var html= new Tech(),
css= new Tech(),
js= new Tech();
Some checking (avoiding console.log)-
html.isPrototypeOf(css); //false
html.isPrototypeOf(js); //false
css.isPrototypeOf(html); //false
css.isPrototypeOf(js); //false
js.isPrototypeOf(html); //false
js.isPrototypeOf(css); //false
Tech.prototype.isPrototypeOf(html); //true
Tech.prototype.isPrototypeOf(css); //true
Tech.prototype.isPrototypeOf(js); //true
How do you think these constructor-style Objects (html , css, js)
Objects differ from the OLOO-style code? In fact they serve the same purpose. In OLOO-style one objects delegate to Tech(delegation was set explicitly) while in constructor-style one objects delegate to Tech.prototype(delegation was set implicitly). Ultimately you end up linking the three objects, having no linkage with each-other, to one object, directly using OLOO-style, indirectly using constructor-style.
"As is, ObjB has to be created from ObjA.. Object.create(ObjB) etc"
No, ObjB here is not like an instance (in classical-based languages) of any class
ObjA. It sould be said like objB object is made delegate to ObjA object at it's creation
time". If you used constructor, you would have done the same 'coupling', although indirectly by making use of .prototypes.
#Marcus #bholben
Perhaps we can do something like this.
const Point = {
statics(m) { if (this !== Point) { throw Error(m); }},
create (x, y) {
this.statics();
var P = Object.create(Point);
P.init(x, y);
return P;
},
init(x=0, y=0) {
this.x = x;
this.y = y;
}
};
const Point3D = {
__proto__: Point,
statics(m) { if (this !== Point3D) { throw Error(m); }},
create (x, y, z) {
this.statics();
var P = Object.create(Point3D);
P.init(x, y, z);
return P;
},
init (x=0, y=0, z=0) {
super.init(x, y);
this.z = z;
}
};
Of course, creating a Point3D object that links to the prototype of a Point2D object is kind of silly, but that's beside the point (I wanted to be consistent with your example). Anyways, as far as the complaints go:
The asymmetry can be fixed with ES6's Object.setPrototypeOf or
the more frowned upon __proto__ = ... that I use. We can also use super on regular objects now too, as seen in Point3D.init(). Another way would be to do something like
const Point3D = Object.assign(Object.create(Point), {
...
}
though I don't particularly like the syntax.
We can always just wrap p = Object.create(Point) and then p.init() into a constructor. e.g. Point.create(x,y). Using the code above we can create a Point3D "instance" in the following manner.
var b = Point3D.create(1,2,3);
console.log(b); // { x:1, y:2, z:3 }
console.log(Point.isPrototypeOf(b)); // true
console.log(Point3D.isPrototypeOf(b)) // true
I just came up with this hack to emulate static methods in OLOO. I'm not sure if I like it or not. It requires calling a special property at the top of any "static" methods. For example, I've made the Point.create() method static.
var p = Point.create(1,2);
var q = p.create(4,1); // Error!
Alternatively, with ES6 Symbols you can safely extend Javascript base classes. So you could save yourself some code and define the special property on Object.prototype. For example,
const extendedJS = {};
( function(extension) {
const statics = Symbol('static');
Object.defineProperty(Object.prototype, statics, {
writable: true,
enumerable: false,
configurable: true,
value(obj, message) {
if (this !== obj)
throw Error(message);
}
});
Object.assign(extension, {statics});
})(extendedJS);
const Point = {
create (x, y) {
this[extendedJS.statics](Point);
...
#james emanon - So, you are referring to multiple inheritance (discussed on page 75 in the book "You Don't Know JS: this & Object Prototypes"). And that mechanism we can find in underscore's "extend" function for example. Names of object you stated in your example are a bit mixing apples, oranges and candies but I understand the point behind. From my experience this would be OOLO version:
var ObjA = {
setA: function(a) {
this.a = a;
},
outputA: function() {
console.log("Invoking outputA - A: ", this.a);
}
};
// 'ObjB' links/delegates to 'ObjA'
var ObjB = Object.create( ObjA );
ObjB.setB = function(b) {
this.b = b;
}
ObjB.setA_B = function(a, b) {
this.setA( a ); // This is obvious. 'setA' is not found in 'ObjB' so by prototype chain it's found in 'ObjA'
this.setB( b );
console.log("Invoking setA_B - A: ", this.a, " B: ", this.b);
};
// 'ObjC' links/delegates to 'ObjB'
var ObjC = Object.create( ObjB );
ObjC.setC = function(c) {
this.c = c;
};
ObjC.setA_C = function(a, c) {
this.setA( a ); // Invoking 'setA' that is clearly not in ObjC shows that prototype chaining goes through ObjB all the way to the ObjA
this.setC( c );
console.log("Invoking setA_C - A: ", this.a, " C: ", this.c);
};
ObjC.setA_B_C = function(a, b, c){
this.setA( a ); // Invoking 'setA' that is clearly not in ObjC nor ObjB shows that prototype chaining got all the way to the ObjA
this.setB( b );
this.setC( c );
console.log("Invoking setA_B_C - A: ", this.a, " B: ", this.b, " C: ", this.c);
};
ObjA.setA("A1");
ObjA.outputA(); // Invoking outputA - A: A1
ObjB.setA_B("A2", "B1"); // Invoking setA_B - A: A2 B: B1
ObjC.setA_C("A3", "C1"); // Invoking setA_C - A: A3 C: C1
ObjC.setA_B_C("A4", "B2", "C1"); // Invoking setA_B_C - A: A4 B: B2 C: C1
It is simple example but the point shown is that we are just chaining object together in rather flat structure/formation and still have possibility to use methods and properties from multiple object. We achieve same things as with class/"copying the properties" approach. Summed by Kyle (page 114, "this & Object Prototypes"):
In other words, the actual mechanism, the essence of what’s important
to the functionality we can leverage in JavaScript, is all about objects
being linked to other objects.
I understand that more natural way for you would be to state all the "parent" (careful :) ) objects in one place/function call rather modeling whole chain.
What it requires is shift in thinking and modeling problems in our applications according to that. I'm also getting used to it. Hope it helps and final verdict from the Kyle himself would be great. :)
#Marcus, just like you, I have been keen on OLOO and also dislike the asymmetry as described in your first point. I've been playing with an abstraction to bring the symmetry back. You could create a link() function that is used in place of Object.create(). When used, your code could look something like this...
var Point = {
init : function(x,y) {
this.x = x;
this.y = y;
}
};
var Point3D = link(Point, {
init: function(x,y,z) {
Point.init.call(this, x, y);
this.z = z;
}
});
Remember that Object.create() has a second parameter that can be passed in. Here is the link function that leverages the second parameter. It also allows a little bit of custom configuration...
function link(delegate, props, propsConfig) {
props = props || {};
propsConfig = propsConfig || {};
var obj = {};
Object.keys(props).forEach(function (key) {
obj[key] = {
value: props[key],
enumerable: propsConfig.isEnumerable || true,
writable: propsConfig.isWritable || true,
configurable: propsConfig.isConfigurable || true
};
});
return Object.create(delegate, obj);
}
Of course, I think #Kyle would not endorse shadowing the init() function in the Point3D object. ;-)
Is there a way to OLOO more than "two" objects.. all the examples I consist of the based example (see OP's example). Lets say we had the following objects, how can we create a "fourth" object that has the attributes of the 'other' three? ala...
var Button = {
init: function(name, cost) {
this.buttonName = name;
this.buttonCost = cost;
}
}
var Shoe = {
speed: 100
}
var Bike = {
range: '4 miles'
}
these objects are arbitrary, and could encompass all sorts of behaviors. But the gist is, we have 'n' number of objects, and our new object needs something from all three.
instead of the given examples ala:
var newObj = Object.create(oneSingularObject);
newObj.whatever..
BUT, our newObject = (Button, Bike, Shoe)......
What is the pattern to get this going in OLOO?
In Stoyan Stefanov's book Object-Oriented javascript, on page 103 he has the following. However when I try this, I get a different result with h instanceof Object. Am I missing something, has something in JS changed since or is this an error in the book.
>>> function Hero(){}
>>> var h = new Hero();
>>> var o = {};
>>> h instanceof Hero;
true
>>> h instanceof Object;
false //true in Google Chrome
>>> o instanceof Object;
true
If that's what the book says, then the book
is incorrect. (And searching the book content in Amazon.com confirms the error.)
Your true result that you get in Google Chrome is the correct result.
While the h object inherits from the .prototype on the Hero function, that .prototype inherits from the .prototype on the Object function. This means that h inherits both from Hero.prototype and Object.prototype, and is considered an instance of both constructors.
The only way it wouldn't be would be if Hero.prototype was an object that did not inherit from Object.prototype. But in that example, it uses the default object, so it does indeed inherit.
Using the instanceof operator you don't test whether something was created by a certain constructor, but whether something inherits from a certain object (whether a certain object is in the prototype chain of something). foo instanceof F has exactly the same result as a recursive* Object.getPrototypeOf(foo) === F.prototype
var F = function() {};
var foo = new F();
foo instanceof F // true
Object.getPrototypeOf(foo) === F.prototype // true
F.prototype = {}; // changed the prototype of F
foo instanceof F // false
Object.getPrototypeOf(foo) === F.prototype // false
foo instanceof Object // true
Object.getPrototypeOf(Object.getPrototypeOf(foo)) === Object.prototype // true
With that in mind, it is pretty obvious that if you don't change the prototype of a function to an object which doesn't inherit from Object.prototype, all the instances constructed with that function as constructor will inherit from Object.prototype, so they will be instances of Object.
F.prototype = Object.create(null);
var bar = new F();
bar instanceof F // true
bar instanceof Object // false
Reference: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/instanceof
instanceof shim (just theoretical purposes, there is no practical use for it):
function instanceOf(object, constructor) {
if (!object) return false;
var object = Object.getPrototypeOf(object);
if (object === constructor.prototype) return true;
return instanceOf(object, constructor);
}
I known this has been asked hundreds of times, however, I can't seem to grasp the concept of prototype
Here's my sample script
var config = {
writable: true,
enumerable: true,
configurable: true
};
var defineProperty = function(obj, name, value) {
config.value = value;
Object.defineProperty(obj, name, config);
}
var man= Object.create(null);
defineProperty(man, 'sex', "male");
var person = Object.create(man);
person.greet = function (person) {
return this.name + ': Why, hello there, ' + person + '.'
}
var p=Object.getPrototypeOf(person);
alert(p.sex);//shows male
person.prototype.age=13;//why there is a error said the prototype is undefined? I thought it supposed be man object...
var child=function(){}
child.prototype.color="red";//why this line doesn't show error? both child and person are an object .
alert(child.prototype.color);//shows red
var ch=Object.getPrototypeOf(child);
alert(ch.color);//why it is undefined? it is supposed red.
Hope you can give me some helps... thanks.
Updated:
Thanks your guys kindly help, Based on Elclanrs's answer, Below is what I learned.
Function is the one of the build-in objects in javascript. the 3 format creation function object are equal.
var function_name = new Function(arg1, arg2, ..., argN, function_body)
function function_name(arg1, arg2, ..., argN)
{
...
}
var function_name=function(arg1, arg2, ..., argN)
{
...
}
So, that is why create a prototype chain we have to create a function and then call it with the new keyword .
Function.prototype is the reference to All the Function object prototype.
Cheers
The prototype property only exists on functions, and person is not a function. It's an object.
Here's what's happening:
var man = Object.create(null); // man (object) -> null
man.sex = "male";
var person = Object.create(man); // person (object) -> man (object) -> null
person.greet = function () { ... };
var p = Object.getPrototypeOf(person); // man (object) -> null
alert(p.sex); // p is the same object as man
person.prototype.age = 13; // person doesn't have a prototype
var child = function () {}; // child (function) -> Function.prototype
// -> Object.prototype -> null
child.prototype.color = "red"; // child has a prototype
var ch = Object.getPrototypeOf(child); // Function.prototype
alert(ch.color); // ch is not the same as color.prototype
// ch is Function.prototype
For more information I suggest you read this answer: https://stackoverflow.com/a/8096017/783743
Edit: To explain what's happening in as few words as possible:
Everything in JavaScript is an object except primitive values (booleans, numbers and strings), and null and undefined.
All objects have a property called [[proto]] which is not accessible to the programmer. However most engines make this property accessible as __proto__.
When you create an object like var o = { a: false, b: "something", ... } then o.__proto__ is Object.prototype.
When you create an object like var o = Object.create(something) then o.__proto__ is something.
When you create an object like var o = new f(a, b, ...) then o.__proto__ is f.prototype.
When JavaScript can't find a property on o it searches for the property on o.__proto__ and then o.__proto__.__proto__ etc until it either finds the property or the proto chain ends in null (in which case the property is undefined).
Finally, Object.getPrototypeOf(o) returns o.__proto__ and not o.prototype - __proto__ exists on all objects including functions but prototype only exists on functions.
I think you might be mixing concepts. Try grasping the concept of prototypes with classic prototype inheritance first, then you can get into all the new Object stuff.
In JavaScript, every object (numbers, strings, objects, functions, arrays, regex, dates...) has a prototype which you can think of as a collection of methods (functions) that are common to all current and future instances of that object.
To create a prototype chain you have to create a function and then call it with the new keyword to specify that it is a constructor. You can think of constructors as the main function that takes the parameters necessary to build new instances of your object.
Having this in mind, you can extend native objects or create your own new prototype chains. This is similar to the concept of classes but much more powerful in practice.
Similar to your example, you could write a prototype chain like this:
// Very basic helper to extend prototypes of objects
// I'm attaching this method to the Function prototype
// so it'll be available for every function
Function.prototype.inherits = function(parent) {
this.prototype = Object.create(parent.prototype);
}
// Person constructor
function Person(name, age, sex) {
// Common to all Persons
this.name = name;
this.age = age;
this.sex = sex;
}
Person.prototype = {
// common to all Persons
say: function(words) {
return this.name +'says: '+ words;
}
};
// Student constructor
function Student(name, age, sex, school) {
// Set the variables on the parent object Person
// using Student as a context.
// This is similar to what other laguanges call 'super'
Person.call(this, name, age, sex);
this.school = school; // unique to Student
}
Student.inherits(Person); // inherit the prototype of Person
var mike = new Student('Mike', 25, 'male', 'Downtown'); // create new student
console.log(mike.say('hello world')); //=> "Mike says: hello world"
In newer version of JavaScript (read EcmaScript) they added new ways to deal with objects and extend them. But the concept it's a bit different from classical prototype inheritance, it seems more complicated, and some more knowledge of how JS works underneath would help to really understand how it works, plus it doesn't work in older browsers. That's why I suggest you start with the classical pattern for which you'll find accurate and abundant information on the internet.
I'm always flabbergasted by the way people try to force some form of classical inheritance into javascript. I have designed a method to inherit in some object b the prototype methods from object a, without adding prototype methods from object b to object a, and the possibility to use private variables from the object inherited from1. Now I'm curious: would you say this is really prototypal 'inheritance'? Is it a viable method? Are there pittfals to it?
Here's some example code:
Object.prototype.inheritsFrom = function(obj){
var prototo = this.prototype,
protofrom = obj.prototype;
for (var l in protofrom) {
if (protofrom.hasOwnProperty(l)){
prototo[l] = protofrom[l];
}
}
}
function Obj1(){
var const1 = 25;
if (!Obj1.prototype.getConst1){
Obj1.prototype.getConst1 = function(){
return const1;
}
}
}
function Obj2(){
var const2 = 50;
if (!Obj2.prototype.getConst2){
Obj2.prototype.getConst2 = function(){
return const2;
}
}
Obj2.inheritsFrom(Obj1);
}
var instanceA = new Obj1,
instanceB = new Obj2;
Now instanceA contains method getConst1, instanceB contains methods getConst1 and getConst2, as you can see in this jsfiddle.
1 By assigning the prototype methods in the constructor function, effectively using the closure created by that.
No, that's not prototypical inheritance. In true prototypical inheritance, changes to the prototype appear in the objects that rely on that prototype. In your example, they don't, because they're only copied.
I'm not saying it may not be another useful form of inheritance for some situations, but it's not prototypical. In some sense I'm not even sure it's inheritance, although I think one could argue it either way and it doesn't really matter regardless.
Here's an example of adding to the prototype:
function Parent() {
}
Parent.prototype.foo = function() {
display("foo!");
};
function Child() {
}
Child.prototype = new Parent();
var c = new Child();
display("[before] typeof c.foo === '" + typeof c.foo + "'");
// shows "[before] typeof c.foo === 'function'"
display("[before] typeof c.bar === '" + typeof c.bar + "'");
// shows "[before] typeof c.bar === 'undefined'"
display("Note that c.bar is currently undefined");
Parent.prototype.bar = function() {
display("bar!");
};
display("[after] typeof c.bar === '" + typeof c.bar + "'");
// shows "[after] typeof c.bar === 'function'"
display("Now c.bar is a function");
c.foo();
c.bar();
Live copy
Note that this is not an obscure case. After all, your own code relies on changes to Object.prototype being reflected in the other things (Function) that have already derived from it.
Off-topic: Strongly recommend never adding anything to Object.prototype. It will break a huge amount of code that assumes that using for..in on a {} would yield no properties. Until you can reliably mark additions as non-enumerable (ECMAScript5 now provides a way to do that, but most implementations don't have it yet), just stay away from Object.prototype. Just a recommendation. Additionally, in your case, it doesn't make sense, because the inheritsFrom only works for Function instances, so you'd want to add it to Function.prototype instead (which is a lot less dangerous).