> It’s interesting because copy and pasting a class gives you something humans love: a template!
That’s exactly what the OS/2 workplace shell did back in the early 90s: You had a “templates” folder where you would drag one of the many notebook-like icons and drop a brand new and empty file of the corresponding type.
When installing OS/2 programs they would register new file types and create a template in this special purpose folder. Man, that were exciting times!
Didn’t Ubuntu also support templates up to a point?
Xcode doesn't go that far but has the plus button in the top-right corner. Clicking it will open a list of snippets. Most language constructs are in there, if/switch/class/struct/etc.
Weird enough I never got used to it. My desire for templates is more on the implementation level. For example when I need to draw a circle, I google for "SwiftUI custom shape", then copy/paste a working example, and from there, edit the "template" until I've got something going.
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.
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.)
yeah, even though the 'letus copy and old file and empty it' to me it shows how average users brain sees and wants to see the computer/filesystem. ex-nihilo isn't natural at their level, and copying something they handled is the path of least resistance. MS should jump on the occasion
I think this was discovered by Alan Kay and team in the 80's and resulted in the implementation later of prototype based computer languages like Self an Javascript
Now what if: for OO languages the virtual methods can be adorned with both an example basic implementation and a comment with instructions.
Then when you do the “implement abstract methods” IDE shortcut it fills in those example implementations.
Basically you are saying “they are going to copy paste anyway, let’s get them started off with a decent example”