|
|
|
|
|
by ZenPsycho
5126 days ago
|
|
@viraptor and so we can see that we must take into account more than just whether one can be simulated on another, we must take into account /expressiveness/, or level of complexity as well! In theory, you could simulate prototypes with classes too. You have to be able to, or else it wouldn't be possible to write an interpreter for a language which supports prototypes. The question of "can" and "can't" then, in the context of my original question has to do with the level of difficulty in doing one or the other. Now that we've got this far, what is more difficult- simulating classes with prototypes, or simulating prototypes with classes? Which requires more code, and more complexity? And from that, what do we conclude about primitiveness? |
|
With classes / prototypes (sorry for wibbly wobbly explanation, my CS is not good enough to use the proper terms, which probably exist out there), you can pretend there's a "behaves like" relationship. To simulate a prototype using a class you have to build the freely accessible dictionary and initialisation/cloning semantics level inside of the class.
To simulate classes using a prototype... that depends on your definition of a class. Dynamic dispatch is already there, encapsulation too, subtypes just need a field specifying the name and cloning the right prototype, inheritance is on by default. Self-referencing is usually in there too.
So in my opinion classes can be substituted by prototypes in a large number of cases. Classes however need another layer on top to act like prototypes. So prototypes look like more primitive than classes and classes look like a special-cased version of prototypes. Then again, it's late here, so maybe I missed something obvious...