[catnaroek]

> That doesn't square with the fact that prototypal OO is strictly more expressive than class-based OO. You can implement class-based OO in a prototypal OO language. You cannot do the converse.

Actually, you can implement prototypal OO in a class-based language. First of all, you need a single class with two members variables and a member function. The member variables are a pointer or reference to a base object, and a hashmap from strings (member names) to objects (member values). In C++, this would be a std::unordered_map<std::string, boost::any>. The member function is an overload of the subscript operator (operator []) that takes a string argument and checks whether the hashmap contains the string as a key. If string is indeed a key, then its associated value is returned. Otherwise, the same subscript operator is evaluated for the base object and the same string. If there is no base object, then either an exception is thrown or a special undefined value is returned.

The feasibility of doing this is no big surprise. After all, dynamically typed languages are a very, very restricted subset of statically typed languages: http://existentialtype.wordpress.com/2011/03/19/dynamic-lang... . The main reason why users of class-based languages do not do this is that this breaks type safety for very little gain.

Actually, the supposed encoding of class-based OO in a prototypal language is not correct from an operational semantics point of view. In a statically typed OO language, methods and member variables must be known to exist, so they are directly used. The prototypal "encoding" fundamentally relies on testing at runtime whether methods or member variables exist, because it uses the mechanism described two paragraphs above. So it actually does something different than what statically typed class-based OO languages do.

> It also has more than it's share of good parts, though, and if used correctly it is a very expressive language.

For me, an expressive language is not a language that lets me encode hacks (after all, even C can do that), but a language that lets me encode mechanically checkable assurances that my code will work in specific ways. This allows other programmers to reuse my code with full confidence that it will work in the way they expect it to.

[nbouscal]

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.

[catnaroek]

> 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.

[nbouscal]

> 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.

[catnaroek]

> 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.

[nbouscal]

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 ;)