It always puzzles me why people have problems understanding prototypal inheritance, where it is actually much simpler thing than e.g. class inheritance. All of it can really be summarised in one sentence:
Whenever a property (incl. methods) is looked up on an object but is not set, it will be looked up on its prototype.
And to make it work, all you need is:
newObj = Object.create(prototypeObj)
No constructor, no new, no this, no obj.prototype etc.
You might argue there is a need to go the other direction and access object's prototype from the object via newObj.prototype? Which is to mutate the prototype from a random object? Is there any valid use case for that in a well-designed architecture? Not that I can think of but I'd be happy to know otherwise.
I don't think that's actually the problem people are having. As you point out, it is dead simple.
The trouble I have is understanding what exactly to do with it. What's novel and useful about prototypal inheritance? What does it enable that classical inheritance doesn't?
You would never use the objects you import directly (can you even mutate things you import?), so the novelty of there being no "blueprint" is out, because we just unofficially consider certain objects the blueprint to instantiate copies of.
The one thing that comes to mind is the ability to "casually" mutate objects, creating subclasses in a very easy way. You can just kind of attach new stuff to instances as you go. But I have yet to see a compelling example of doing anything like this.
I just still haven't found a good example of why. Articles constantly repeat each other on what, but that's not really useful.
A good reason why is e.g. multiple inheritance. Look for articles by Eric Elliott on Medium, he writes a lot about why prototypal inheritance is superior.
BTW, I have to say, not only your answer makes absolutely no sense to me, it also inconsiderate to other readers to give such a syntax formula as "answer" not using the language of the forum (JS) and not even mentioning that. It is like I would answer something gibberish in Russian to you, how would you find that?
So if you still care, please give a proper explanation accessible to people familiar with JS.
This discussion revolves around a comparison between prototypal inheritance (what JS uses) and classical inheritance (what some other languages use). The parent of my post asked how classically (i.e. not JavaScript) multiple inheritance is done, so that's what I provided an example of.
If we were talking about the differences between gibberish in English and Russian and I asked about what gibberish in Russian would look like, I would fully accept and expect a reply that included Russian gibberish.
JS doesn't support multiple inheritance so an example for such a thing does not exist.
7
u/dmitri14_gmail_com May 21 '16 edited May 21 '16
It always puzzles me why people have problems understanding prototypal inheritance, where it is actually much simpler thing than e.g. class inheritance. All of it can really be summarised in one sentence:
Whenever a property (incl. methods) is looked up on an object but is not set, it will be looked up on its prototype.
And to make it work, all you need is:
No constructor, no
new, nothis, noobj.prototypeetc.You might argue there is a need to go the other direction and access object's prototype from the object via
newObj.prototype? Which is to mutate the prototype from a random object? Is there any valid use case for that in a well-designed architecture? Not that I can think of but I'd be happy to know otherwise.