[anonymoushn]

Well, it would help my understanding if you could elaborate on your disagreement rather than just saying that you disagree.

The additional constraint of not creating a new object system prevents me from making OO of any kind at all in C, but leaves most scripting languages that implement "classical inheritance" very open to implementing "prototypal inheritance". This is partly because they actually use "prototypal inheritance" and expose a "classical interface" as the primary one, so fiddling with __mro__ feels a little like cheating. If I want to avoid fiddling with the existing __mro__ and build my own, I can override __getattribute__. This certainly doesn't feel like making a new object system to me, but it also doesn't feel substantially different from overriding [] in C++.

[catnaroek]

To be honest, I have no idea how to implement the exact operational semantics of prototypal inheritance in a dynamic language with classes. (Perhaps it is possible, but I would not bet on it.) In JavaScript, objects are statically known to be internally a pair of a base reference and a hashmap. In Python, you can define a tuple or class that has a base reference and a hashmap as members, but internally your program will test for the existence of these members all the time. So, different semantics.

But a static OO language can faithfully reproduce the operational semantics of prototypal inheritance.

[anonymoushn]

The difference between "checking for the existence of the proto key in a hash map" and "checking whether the proto pointer that I am certain to have points to NULL" is due entirely to the differences in the semantics of Python and C++. Is it important just to implement prototypes, or to ensure that the guts of the prototype system are the same as the guts of a particular JS implementation? I'm not sure precisely where the goalposts have gone, so here are some prototypes in Python. http://pastie.org/8263966

Edit: Now with method binding that works instead of not working!