2 ms·

This sounds an awful lot like prototype inheritance. Turns out people don't seem to like it - it's essentially vestigal in javascript these days, most people s

This sounds an awful lot like prototype inheritance. Turns out people don't seem to like it - it's essentially vestigal in javascript these days, most people seem to use the class system built on top of it and that was true even in the good old days before support for it was added to the language keywords. It was rare to find code that actually used prototypes as prototypes rather than slightly odd ways of defining classes.

squiggleblaz 5y ago
I don't think the problem with prototype inheritance comes from whether people like creating things by taking something that already exists and modifying it. In fact, people very often use classical inheritance to emulate prototypical inheritance ("oh, i'll just add an extra method here and override that method there"). The problems normally relate to maintenance and change over time: 1. We reject classical-inheritance-emulating-prototypical-inheritance because it makes it hard to change the original. But copying a file and changing it doesn't have this problem, since the copy and the original are forks. If you need to make changes to both files, then you need to make changes to both files. 2. We prefer classical inheritance because a class is a description of how you can use an instance of that class. The class definition is usually very declarative and lends itself to great tooling support. Prototypical inheritance is imperative by its nature. This means there's no generic answer to the question, "How can I use this object", but only "how can I use this object right now?". But copying a file and changing it doesn't have this problem, since the copy and original are data, whose use is determined by external tools. Another commenter in this thread specifically claims that prototypical inheritance was derived from this model (with a sense of optimism and joy, I think). But the fact that one extension of this model failed didn't mean the whole model is a failure. In this case, the suggestion is just to recognise what a user is doing and facilitate that. I think that's a lot less trouble than a language feature. (Actually, I think Jet Brains IDEs have a lot of features that tend towards this. They just might not be quite there.)

squiggleblaz 5y ago

I don't think the problem with prototype inheritance comes from whether people like creating things by taking something that already exists and modifying it. In fact, people very often use classical inheritance to emulate prototypical inheritance ("oh, i'll just add an extra method here and override that method there"). The problems normally relate to maintenance and change over time: 1. We reject classical-inheritance-emulating-prototypical-inheritance because it makes it hard to change the original. But copying a file and changing it doesn't have this problem, since the copy and the original are forks. If you need to make changes to both files, then you need to make changes to both files. 2. We prefer classical inheritance because a class is a description of how you can use an instance of that class. The class definition is usually very declarative and lends itself to great tooling support. Prototypical inheritance is imperative by its nature. This means there's no generic answer to the question, "How can I use this object", but only "how can I use this object right now?". But copying a file and changing it doesn't have this problem, since the copy and original are data, whose use is determined by external tools. Another commenter in this thread specifically claims that prototypical inheritance was derived from this model (with a sense of optimism and joy, I think). But the fact that one extension of this model failed didn't mean the whole model is a failure. In this case, the suggestion is just to recognise what a user is doing and facilitate that. I think that's a lot less trouble than a language feature. (Actually, I think Jet Brains IDEs have a lot of features that tend towards this. They just might not be quite there.)