/    Sign up×
Community /Pin to ProfileBookmark

prototype inheritance

Copy linkTweet thisAlerts:
Nov 09.2010

Hey all,

In this line:

[CODE]
function inherit(C, P) {
var F = function () {};
F.prototype = P.prototype;
C.prototype = new F();
}
[/CODE]

Someone said that:

[CODE]
The new inheriting function will actually separate the constructor of the parent from the child, because it’s not pointing to the same object anymore, but now it’s pointing to a prototype of a newly created function that has nothing to do with the parent. So, you actually create a local copy of the parent’s constructor, and then create a new instance of the copy, which returns all constructor methods an properties. By changing the constructor of the child now, it will not affect the parent.
[/CODE]

My question is I don’t understand how the child has nothing to do with the parent anymore when indeed we ASSIGN A REFERENCE of P prototype to F prototype. So F prototype must be pointing to P’s prototype. When we instantiate F, the above quote says it contains a copy, but not a reference? apply() creates COPIES but object assignment creates REFERENCES so when assigning prototype, isn’t a refeence, not a copy, created from P to F? And if it’s a reference, then that link from C to F to P should still exist. But obviously it doesn’t in the language so I am clearly missing something.

Thanks for any clarification.

to post a comment
JavaScript

5 Comments(s) ↴

Copy linkTweet thisAlerts:
@rnd_meNov 09.2010 — it's basically c.prototype.prototype=P.prototype .

it doesn't copy, but the author is right that you can mod the child's prototype without affecting the parent's prototype.

[CODE]function inherit(C, P) {
var F = function () {};
F.prototype = P.prototype;
C.prototype = new F();
}


function A(){
this.a=1;
}

function B(){
this.b=2;
}

B.prototype.prop=true;

inherit(A,B);

var o=new A;

o.prop=5;

alert((new B()).prop)[/CODE]
Copy linkTweet thisAlerts:
@KorNov 09.2010 — Or, in other words: JavaScript uses the [I]delegation[/I], [I]not the inheritance[/I]. And that delegation is subsequent to a process of "cloning" the object, object which serves as a [B]prototype[/B].

JavaScript is a prototype based language, not a class based one.
Copy linkTweet thisAlerts:
@JohnMerlinoauthorNov 13.2010 — I'm looking at this from memory position angle. Because F's prototype points to the same memory position as P's prototype and because prototype is an object and objects get passed around by reference so they reference same memory position during assignment.

p _proto_ (memory position 001)

F.prototype = P.prototype;

F _proto_ (memory position 001)

C.prototype = new F();

C _proto_ (memory position 001)

So if interpreter can't find property in C's _proto_, it looks up parent object F and checks if it has the _proto_ property and if it doesn't, then it searches P. Hence, C can inherit from P.

But when you change C, and if C points to memory position 001, how can P not be affected, if P itself points to memory position 001?

You mentioned it's like C.prototype.prototype = P.prototype;

I don't see how the language interprets that prototype property has a property called prototype when it's not outright declared. All C's prototype does is point to an object, which has its own prototype.

I've been stuck on understanding this for a week. Someone please explain why my memory position argument fails (despite the fact that objects passed by reference) and how one of the answers said that behind scenes a new prototype object is creared on C's prototype without ever being declared as an object. In reality, it's just a reference to an object.

Confused.
Copy linkTweet thisAlerts:
@rnd_meNov 13.2010 — 
But when you change C, and if C points to memory position 001, how can P not be affected, if P itself points to memory position 001?
[/QUOTE]

C!=P. Changing C should have no effect on P. Changing P should have an effect on C. Remember, P is a property of C, reached by the special link .prototype. Consider:

[CODE]var myProto={a:1};

var F = function f() {};
F.prototype = myProto;
var C= new F();

var F2 = function f2() {};
F2.prototype = C;
var D = new F2();


D.prototype==undefined
D.prototype=34; //try to kill link
D.a==1
[/CODE]

you can see that D reaches myProto, because D has an inherited .a prop that equals 1, just like myProto. Also notice that you can't see or touch the .prototype of the instance. This is because .prototype is a "special" property that executes a different internal getter than normal, "own", properties. It is marked "DontEnum", so there's no way you can see it from the js runtime, save a few bugs over the years.


I don't see how the language interprets that prototype property has a property called prototype when it's not outright declared. All C's prototype does is point to an object, which has its own prototype.
[/QUOTE]


according to the spec, the "new" operator create a new empty object from ObjectObject. It then assigns another object to the new object's prototype property. Finally, it executes the code within the constructor to assign own properties to the new object. you should really read the ecmascript spec to get a firm handle on how "new" relates to "prototype".
Copy linkTweet thisAlerts:
@JohnMerlinoauthorJan 06.2011 — Thanks your explanation was the best.
×

Success!

Help @JohnMerlino spread the word by sharing this article on Twitter...

Tweet This
Sign in
Forgot password?
Sign in with TwitchSign in with GithubCreate Account
about: ({
version: 0.1.9 — BETA 5.20,
whats_new: community page,
up_next: more Davinci•003 tasks,
coming_soon: events calendar,
social: @webDeveloperHQ
});

legal: ({
terms: of use,
privacy: policy
});
changelog: (
version: 0.1.9,
notes: added community page

version: 0.1.8,
notes: added Davinci•003

version: 0.1.7,
notes: upvote answers to bounties

version: 0.1.6,
notes: article editor refresh
)...
recent_tips: (
tipper: @AriseFacilitySolutions09,
tipped: article
amount: 1000 SATS,

tipper: @Yussuf4331,
tipped: article
amount: 1000 SATS,

tipper: @darkwebsites540,
tipped: article
amount: 10 SATS,
)...