javascript inheritance using setPrototypeOf











up vote
1
down vote

favorite












I read here we can use Object.create to achieve inheritance



Here is an example with a Rectangle which inherits from Shape



function Shape() {}

function Rectangle() {
Shape.call(this);
}

Rectangle.prototype = Object.create(Shape.prototype);
Rectangle.prototype.constructor = Rectangle;

var rect = new Rectangle();


I am wondering if using Object.setPrototypeOf instead of Object.create is correct ?



function Shape() {}

function Rectangle() {
Shape.call(this);
}

Object.setPrototypeOf(Rectangle.prototype, Shape.prototype);

var rect = new Rectangle();


If it's correct, then I am wondering why so many examples show inheritance with Object.create because you need to worry about the constructor property when using this method.



With Object.setPrototypeOf you don't need to redefine the consctrutor prop, I find it safer and simpler.










share|improve this question






















  • Setting the constructor property is more like a nice-to-have. It is not required.
    – trincot
    Nov 10 at 18:29










  • it's required if we using in one of our method -> developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/…
    – Olivier Boissé
    Nov 10 at 18:41










  • That is the nice-to-have I talk about, but if one wanted to, they could keep this information in another way. It is not that JavaScript native methods or operators will break or behave differently if you don't set the constructor property. It is only there to facilitate. It is not essential.
    – trincot
    Nov 10 at 18:45

















up vote
1
down vote

favorite












I read here we can use Object.create to achieve inheritance



Here is an example with a Rectangle which inherits from Shape



function Shape() {}

function Rectangle() {
Shape.call(this);
}

Rectangle.prototype = Object.create(Shape.prototype);
Rectangle.prototype.constructor = Rectangle;

var rect = new Rectangle();


I am wondering if using Object.setPrototypeOf instead of Object.create is correct ?



function Shape() {}

function Rectangle() {
Shape.call(this);
}

Object.setPrototypeOf(Rectangle.prototype, Shape.prototype);

var rect = new Rectangle();


If it's correct, then I am wondering why so many examples show inheritance with Object.create because you need to worry about the constructor property when using this method.



With Object.setPrototypeOf you don't need to redefine the consctrutor prop, I find it safer and simpler.










share|improve this question






















  • Setting the constructor property is more like a nice-to-have. It is not required.
    – trincot
    Nov 10 at 18:29










  • it's required if we using in one of our method -> developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/…
    – Olivier Boissé
    Nov 10 at 18:41










  • That is the nice-to-have I talk about, but if one wanted to, they could keep this information in another way. It is not that JavaScript native methods or operators will break or behave differently if you don't set the constructor property. It is only there to facilitate. It is not essential.
    – trincot
    Nov 10 at 18:45















up vote
1
down vote

favorite









up vote
1
down vote

favorite











I read here we can use Object.create to achieve inheritance



Here is an example with a Rectangle which inherits from Shape



function Shape() {}

function Rectangle() {
Shape.call(this);
}

Rectangle.prototype = Object.create(Shape.prototype);
Rectangle.prototype.constructor = Rectangle;

var rect = new Rectangle();


I am wondering if using Object.setPrototypeOf instead of Object.create is correct ?



function Shape() {}

function Rectangle() {
Shape.call(this);
}

Object.setPrototypeOf(Rectangle.prototype, Shape.prototype);

var rect = new Rectangle();


If it's correct, then I am wondering why so many examples show inheritance with Object.create because you need to worry about the constructor property when using this method.



With Object.setPrototypeOf you don't need to redefine the consctrutor prop, I find it safer and simpler.










share|improve this question













I read here we can use Object.create to achieve inheritance



Here is an example with a Rectangle which inherits from Shape



function Shape() {}

function Rectangle() {
Shape.call(this);
}

Rectangle.prototype = Object.create(Shape.prototype);
Rectangle.prototype.constructor = Rectangle;

var rect = new Rectangle();


I am wondering if using Object.setPrototypeOf instead of Object.create is correct ?



function Shape() {}

function Rectangle() {
Shape.call(this);
}

Object.setPrototypeOf(Rectangle.prototype, Shape.prototype);

var rect = new Rectangle();


If it's correct, then I am wondering why so many examples show inheritance with Object.create because you need to worry about the constructor property when using this method.



With Object.setPrototypeOf you don't need to redefine the consctrutor prop, I find it safer and simpler.







javascript prototype prototypal-inheritance






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 10 at 18:21









Olivier Boissé

3,1301025




3,1301025












  • Setting the constructor property is more like a nice-to-have. It is not required.
    – trincot
    Nov 10 at 18:29










  • it's required if we using in one of our method -> developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/…
    – Olivier Boissé
    Nov 10 at 18:41










  • That is the nice-to-have I talk about, but if one wanted to, they could keep this information in another way. It is not that JavaScript native methods or operators will break or behave differently if you don't set the constructor property. It is only there to facilitate. It is not essential.
    – trincot
    Nov 10 at 18:45




















  • Setting the constructor property is more like a nice-to-have. It is not required.
    – trincot
    Nov 10 at 18:29










  • it's required if we using in one of our method -> developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/…
    – Olivier Boissé
    Nov 10 at 18:41










  • That is the nice-to-have I talk about, but if one wanted to, they could keep this information in another way. It is not that JavaScript native methods or operators will break or behave differently if you don't set the constructor property. It is only there to facilitate. It is not essential.
    – trincot
    Nov 10 at 18:45


















Setting the constructor property is more like a nice-to-have. It is not required.
– trincot
Nov 10 at 18:29




Setting the constructor property is more like a nice-to-have. It is not required.
– trincot
Nov 10 at 18:29












it's required if we using in one of our method -> developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/…
– Olivier Boissé
Nov 10 at 18:41




it's required if we using in one of our method -> developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/…
– Olivier Boissé
Nov 10 at 18:41












That is the nice-to-have I talk about, but if one wanted to, they could keep this information in another way. It is not that JavaScript native methods or operators will break or behave differently if you don't set the constructor property. It is only there to facilitate. It is not essential.
– trincot
Nov 10 at 18:45






That is the nice-to-have I talk about, but if one wanted to, they could keep this information in another way. It is not that JavaScript native methods or operators will break or behave differently if you don't set the constructor property. It is only there to facilitate. It is not essential.
– trincot
Nov 10 at 18:45














1 Answer
1






active

oldest

votes

















up vote
1
down vote













Sometimes your code may rely on the constructor property, which allows you to access the constructor without knowing its function name explicitly. But besides that, there is no real need to set it.



For example, the instanceof operator does not depend on it.



If you don't need to bother about it in your own suggested solution, then you also would not need it in the Object.create solution.



The reason to prefer the Object.create method is that Object.setPrototypeOf may impact the efficiency of your code, as is warned about in the mdn documentation. This does not happen with the Object.create method.






share|improve this answer





















  • with my solution (using Object.setPrototypeOf(Rectangle.prototype, Shape.prototype);) it doesn't reaffect the Rectangle.prototype object, so Cat.prototype.constructor === Cat returns true (Cat.prototype.constructor is still valid)
    – Olivier Boissé
    Nov 10 at 18:44












  • Yes, I see, but still: changing the prototype property is a relatively light operation compared to calling setPrototypeOf.
    – trincot
    Nov 10 at 18:47












  • ok so it's preferable to use Object.create because of performance
    – Olivier Boissé
    Nov 10 at 18:49










  • Yep, it boils down to that.
    – trincot
    Nov 10 at 18:49











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














 

draft saved


draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53242053%2fjavascript-inheritance-using-setprototypeof%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
1
down vote













Sometimes your code may rely on the constructor property, which allows you to access the constructor without knowing its function name explicitly. But besides that, there is no real need to set it.



For example, the instanceof operator does not depend on it.



If you don't need to bother about it in your own suggested solution, then you also would not need it in the Object.create solution.



The reason to prefer the Object.create method is that Object.setPrototypeOf may impact the efficiency of your code, as is warned about in the mdn documentation. This does not happen with the Object.create method.






share|improve this answer





















  • with my solution (using Object.setPrototypeOf(Rectangle.prototype, Shape.prototype);) it doesn't reaffect the Rectangle.prototype object, so Cat.prototype.constructor === Cat returns true (Cat.prototype.constructor is still valid)
    – Olivier Boissé
    Nov 10 at 18:44












  • Yes, I see, but still: changing the prototype property is a relatively light operation compared to calling setPrototypeOf.
    – trincot
    Nov 10 at 18:47












  • ok so it's preferable to use Object.create because of performance
    – Olivier Boissé
    Nov 10 at 18:49










  • Yep, it boils down to that.
    – trincot
    Nov 10 at 18:49















up vote
1
down vote













Sometimes your code may rely on the constructor property, which allows you to access the constructor without knowing its function name explicitly. But besides that, there is no real need to set it.



For example, the instanceof operator does not depend on it.



If you don't need to bother about it in your own suggested solution, then you also would not need it in the Object.create solution.



The reason to prefer the Object.create method is that Object.setPrototypeOf may impact the efficiency of your code, as is warned about in the mdn documentation. This does not happen with the Object.create method.






share|improve this answer





















  • with my solution (using Object.setPrototypeOf(Rectangle.prototype, Shape.prototype);) it doesn't reaffect the Rectangle.prototype object, so Cat.prototype.constructor === Cat returns true (Cat.prototype.constructor is still valid)
    – Olivier Boissé
    Nov 10 at 18:44












  • Yes, I see, but still: changing the prototype property is a relatively light operation compared to calling setPrototypeOf.
    – trincot
    Nov 10 at 18:47












  • ok so it's preferable to use Object.create because of performance
    – Olivier Boissé
    Nov 10 at 18:49










  • Yep, it boils down to that.
    – trincot
    Nov 10 at 18:49













up vote
1
down vote










up vote
1
down vote









Sometimes your code may rely on the constructor property, which allows you to access the constructor without knowing its function name explicitly. But besides that, there is no real need to set it.



For example, the instanceof operator does not depend on it.



If you don't need to bother about it in your own suggested solution, then you also would not need it in the Object.create solution.



The reason to prefer the Object.create method is that Object.setPrototypeOf may impact the efficiency of your code, as is warned about in the mdn documentation. This does not happen with the Object.create method.






share|improve this answer












Sometimes your code may rely on the constructor property, which allows you to access the constructor without knowing its function name explicitly. But besides that, there is no real need to set it.



For example, the instanceof operator does not depend on it.



If you don't need to bother about it in your own suggested solution, then you also would not need it in the Object.create solution.



The reason to prefer the Object.create method is that Object.setPrototypeOf may impact the efficiency of your code, as is warned about in the mdn documentation. This does not happen with the Object.create method.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 10 at 18:37









trincot

113k1476109




113k1476109












  • with my solution (using Object.setPrototypeOf(Rectangle.prototype, Shape.prototype);) it doesn't reaffect the Rectangle.prototype object, so Cat.prototype.constructor === Cat returns true (Cat.prototype.constructor is still valid)
    – Olivier Boissé
    Nov 10 at 18:44












  • Yes, I see, but still: changing the prototype property is a relatively light operation compared to calling setPrototypeOf.
    – trincot
    Nov 10 at 18:47












  • ok so it's preferable to use Object.create because of performance
    – Olivier Boissé
    Nov 10 at 18:49










  • Yep, it boils down to that.
    – trincot
    Nov 10 at 18:49


















  • with my solution (using Object.setPrototypeOf(Rectangle.prototype, Shape.prototype);) it doesn't reaffect the Rectangle.prototype object, so Cat.prototype.constructor === Cat returns true (Cat.prototype.constructor is still valid)
    – Olivier Boissé
    Nov 10 at 18:44












  • Yes, I see, but still: changing the prototype property is a relatively light operation compared to calling setPrototypeOf.
    – trincot
    Nov 10 at 18:47












  • ok so it's preferable to use Object.create because of performance
    – Olivier Boissé
    Nov 10 at 18:49










  • Yep, it boils down to that.
    – trincot
    Nov 10 at 18:49
















with my solution (using Object.setPrototypeOf(Rectangle.prototype, Shape.prototype);) it doesn't reaffect the Rectangle.prototype object, so Cat.prototype.constructor === Cat returns true (Cat.prototype.constructor is still valid)
– Olivier Boissé
Nov 10 at 18:44






with my solution (using Object.setPrototypeOf(Rectangle.prototype, Shape.prototype);) it doesn't reaffect the Rectangle.prototype object, so Cat.prototype.constructor === Cat returns true (Cat.prototype.constructor is still valid)
– Olivier Boissé
Nov 10 at 18:44














Yes, I see, but still: changing the prototype property is a relatively light operation compared to calling setPrototypeOf.
– trincot
Nov 10 at 18:47






Yes, I see, but still: changing the prototype property is a relatively light operation compared to calling setPrototypeOf.
– trincot
Nov 10 at 18:47














ok so it's preferable to use Object.create because of performance
– Olivier Boissé
Nov 10 at 18:49




ok so it's preferable to use Object.create because of performance
– Olivier Boissé
Nov 10 at 18:49












Yep, it boils down to that.
– trincot
Nov 10 at 18:49




Yep, it boils down to that.
– trincot
Nov 10 at 18:49


















 

draft saved


draft discarded



















































 


draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53242053%2fjavascript-inheritance-using-setprototypeof%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Florida Star v. B. J. F.

Danny Elfman

Retrieve a Users Dashboard in Tumblr with R and TumblR. Oauth Issues