That's a pretty good try, but that does not implement the full flexibility of prototypal OO. Also, note that I wasn't talking about statically-typed class-based OO specifically. Classical OO exists in plenty of dynamic languages too, so your comments about type systems are kind of out of place. I prefer static typing too (as long as it comes with inference and polymorphism), but that's orthogonal to the discussion at hand.
> That's a pretty good try, but that does not implement the full flexibility of prototypal OO.
Are you talking about JavaScript's "this" keyword? I did not mention it in my preceding comment, because that is an implementation detail of JavaScript functions. I think my point still stands that (static) class-based OO languages are sufficiently powerful to encode the semantics of prototypal inheritance.
> Also, note that I wasn't talking about statically-typed class-based OO specifically. Classical OO exists in plenty of dynamic languages too, so your comments about type systems are kind of out of place.
You have a point there. When they say "classes", I usually think C++ classes or Eiffel classes, but you are right that there are dynamic languages that uses classes, too.
> that is an implementation detail of JavaScript functions.
Oh? So in an example where B has a method m, and A inherits from B, how is it that `this` refers to something different when calling B.m() than when calling A.m()? They're the exact same function.
That said, I do need to clarify. I was talking about implementing classical inheritance with prototypal inheritance, and implementing prototypal inheritance with classical inheritance. You can implement either using base language features if you want to create a new object system, but that's not what I was referring to.
> Oh? So in an example where B has a method m, and A inherits from B, how is it that `this` refers to something different when calling B.m() than when calling A.m()? They're the exact same function.
Just like in regular class-based OO languages, "this" is an implicit argument of every method that refers to the object on which the method was invoked.
You can even avoid manually doing all the "this" juggling yourself: Make a delegate class, which holds a reference to a method (including its captured variables) and a reference to the "this" object. When a method is retrieved from a an object, actually construct a delegate referencing both the method and the object. (If the method is retrieved after traversing the inheritance chain "upwards", fix the "this" reference along the way "downwards".) Finally, when a delegate is assigned to a variable or as a member of another object, get rid of the "this" reference and assign the method only instead. Client code never gets to see the "this" juggling.
Oh I know how to implement it, I was just responding to your claim that it was "an implementation detail of JavaScript functions." It's an implementation detail of method calls, the function itself is completely this-agnostic. I guess I was just being pedantic ;)
