TL;DR: long winded bad analogy, but maybe helpful That doesn't sound quite right to me. Not that it is wrong, but maybe looking at it the wrong way? For the d

TL;DR: long winded bad analogy, but maybe helpful That doesn't sound quite right to me. Not that it is wrong, but maybe looking at it the wrong way? For the discussion, I propose an object has some state, and can receive messages and send messages in response. A class is the abstract idea of what an object should be like. To break out the bad analogies, it's like ordering from a restaurant menu. You ask the runtime for an instance of a class. If you want something special, you have to have it put on the menu first. Prototype restaurants have no menus, but they have the dishes on display, and you can order those. Or, if you're so inclined, just point at your neighbours' food and order what that guy's having. If he's eaten half of it already, you'll only get as much as he has left, but luckily you can add combine it with other dishes or ingredients as you go. You can see that if we put some rules in place about which objects can be copied, and what happens during copying exactly, and we call some special objects classes, and use them to create other special objects we call instances, a prototype-based object system can be made to behave like any class-based object system. If we bake those special rules into the language, we make the computer's job easier with hard-wired shortcuts.