0

So...I've been programming for 40 years, from machine language to C++ to Javascript/Typescript. Last 10 years heavily in Javascript.

I seem to stumble when asked about prototypical vs. classical inheritance. I keep reading articles, I keep trying to rehearse, but...honestly, I feel like I understand the concepts but don't know how to give interviewers what they want.

C++ is my frame of reference for classical inheritance (as well as Java and C# which I've also programmed in). Here inheritance is static - you create an object from a class, and that's that.

Javascript is of course dynamic. You create an object which has a prototype that itself has a prototype, and those prototypes have methods and properties which can be extended at runtime and will be available to all objects that share that prototype chain.

Ok, cool.

I understand all that. But I can't seem to give interviewers what they want to hear. In all honesty, I use class and extends and Typescript interfaces and while I know it's different under the hood, the only real practical difference I experience is that you can modify prototypes at runtime for things like polyfills (implementing missing functionality).

So...help. I feel like the knowledge is all in my head, but I don't know how to convey it properly.

Scott Schafer
  • 487
  • 3
  • 14
  • what about: https://medium.com/javascript-scene/master-the-javascript-interview-what-s-the-difference-between-class-prototypal-inheritance-e4cd0a7562e9 - does this help? – azbarcea Sep 14 '19 at 00:15
  • https://stackoverflow.com/questions/41028673/shorthand-for-object-create-with-multiple-properties/41028806#41028806 – Scott Marcus Sep 14 '19 at 00:18
  • Everything you say does make sense ... I'm not sure what you are looking for ... – Jonas Wilms Sep 14 '19 at 00:18
  • https://stackoverflow.com/questions/40917604/javascript-prototype-overriding/40917673#40917673 – Scott Marcus Sep 14 '19 at 00:19
  • @azbarcea Not really. I've watched that. He actually abandons even prototypical inheritance and talks about composition at the end. – Scott Schafer Sep 14 '19 at 00:21
  • 1
    I'n my experience initial interviews are performed by non-technical people and they are looking for specific keywords in responses. Perhaps they're looking the the magic phrase "multiple inheritance" which is not something that is supported by most languages with classical inheritance (like C# and Java). It's hard to say what they wanted, we can only speculate. – Jake Holzinger Sep 14 '19 at 00:49
  • Now I'm suspecting that when they ask about "classical inheritance" they are really asking about a Javascript coding pattern - that is, new vs Object.create()! I was thinking in terms of strongly typed languages. Experience can be a handicap. – Scott Schafer Sep 14 '19 at 00:54
  • Seems like there are different opinions about what “prototype inheritance” means. If Wikipedia can be trusted, this was quite insightful: https://en.m.wikipedia.org/wiki/Prototype-based_programming – Felix Kling Sep 14 '19 at 06:34

1 Answers1

0

Disclaimer: I am still an undergrad with very limited experience.

I realised the difference between these two while implementing Finite Field Algebra. We have:

class Field{
    int p;
    Field (int p){
        this->p = p;
    }
};
class FieldElement: public Field{
    int x; 
    FieldElement(int x, int p) : Field(p){
        this->x = x;
    }
};

Now here, each field element has it's own field and stores all information about that field(which happens to be just an integer p here). Imagine if Field class was very heavy and then we have many objects of FieldElement type. Each object would carry its bulky field. Instead, javascript type prototype chain can be thought of as just carrying a pointer to the Field object which the element belongs to.

Hope I answered your question satisfactorily.

Orwell
  • 37
  • 4
  • I think you're asking the right questions, but... what do you mean by "very heavy"? You could add a lot of methods to the Field class. But in either JS or C++, this wouldn't add to the size of an instance of the Field object (assuming the method is added to the JS prototype). Let's say you added a lot of member data to the Field class. Now in either JS or C++, an instance of the Field class would be equally bulky. – Scott Schafer Oct 14 '19 at 14:05
  • "Now in either JS or C++, an instance of the Field class would be equally bulky" - yes, an instance of the Field would be equally bulky. But an instance of FieldElement would not be. (Again, I don't have much experience, more so in JS). In JS, if we had var a = {}; and var b = {"name": "Scott"}; and if we did Object.setPrototypeOf(a, b), we could access a.name and it'd return Scott. If we now do b["name"] = "Orwell", a.name also returns "Orwell". That means a doesn't store anything with itself except just a reference to b. So even if b has many members, a will continue to be of the same size. – Orwell Oct 14 '19 at 19:06
  • Sure, but a.name isn't a property of 'a', but a property of a's prototype. It's basically a class instance field (aka static member data) - any object that uses this prototype would have the same 'name' field. You're right that 'name' doesn't add 'a' object, but it would mean that different instances using the same prototype couldn't have different 'name' values. IMO, this ambiguity is why some people hate JS. ;) In TypeScript, you could simply write `class A { static name: string; }` and make it explicit. Anyway, I'm feeling that this is more of a difference of syntax than anything else. – Scott Schafer Oct 15 '19 at 17:22