Which one subsumes the other: class-based object-orientation or prototypal inheritance?

Question

In this talk: http://www.youtube.com/watch?v=hQVTIJBZook, Douglas Crockford claims that class-based object-orientation can be represented in terms of prototypal inheritance. The construction he gives is something like:

var theObject = function() {
  var private1 = ...;
  var private2 = ...;
  ...
  return {
    public1: ...,
    public2: ...,
    ...
  };
};

He also claims that the converse is not true: prototypal inheritance cannot be in general encoded using class-based constructs only. I have been thinking about it for a while, and it seems to me that both claims are wrong.

1. The supposed "encoding" of class-based object-orientation is wrong from an operational semantics point of view. In a typical class-based object-oriented language, member variables and functions are known to exist, so they can be directly used. The prototypal "encoding" relies on testing at runtime whether a member is present in an object/hashtable. Ergo, the semantics are different.

2. Prototypal inheritance actually can be encoded in a class-based object-oriented language.

I will use C++ as an example, but any other class-based object-oriented language could be used.

struct prototypal
{
  std::shared_ptr<prototypal> base;
  std::unordered_map<std::string, boost::any> members;

  boost::any & operator [] (const std::string & key)
  {
    auto it = members.find (key);
    if (it == members.end ())
    {
      if (base)
        return (*base) [key];
      else
        throw std::logic_error { "Member not found." };
    }
    else
      return *it;
  }
};

Is my analysis wrong? Am I missing something?

Answer 1

Back in the day, there were no C++ compilers. The C++ code you wrote would be turned into C by a program called CFront. Now, obviously C doesn't have OO capabilities in itself, but somehow the C++ constructs were still turned into C code and your C++ programs were compiled and ran.

This is what he's talking about - you can replicate a C++ class by creating a plain struct and populating it with function pointers to the class methods. You can create a set of function pointers that refer to base classes functions too, so all the OO features that are not present in C can be replicated in C.

This function pointer approach is prototyping. Its a form of fundamental programming that might not be as easy as a language that wraps it up so the compiler handles creating these constructs - so a high level language cannot replicate the low-level features simply because it only provides an easy way of doing things and the compiler will mange them down to low-level features that you do not have access to. Conversely, the low-level language can provide the high-level constructs even though you will have a harder time coding them.

(note, this doesn't necessarily apply to C and C++ as C++ still offers the low-level features, but I hope it demonstrates my answer).

Answer 2

If a language misses a feature which other languages have, you can often simulate that feature - that's true, I am sure you know that one can for example simulate objects and classes in C.

In your 2nd example, you "simulate" prototypal inheritance, but that does not make it a real feature of C++. That means, where things will work seamlessly in Javascript, in C++ you will have to add a lot of more code on your own to make your simulation complete (and it will still be a proprietary extension of yours, which will "feel" artificial for most other C++ guys).

The first example shows the standard way of creating more than one object of the same kind in Javascript - this does not "feel" like an artifical simulation of class based inheritance, and it will mostly serve the same purpose as classes in C++ from a practical point of view - to create many objects of the same type. Of course, there are semantic differences, as Jan Hudec explained from the fact that the one language is statically typed, and the other dynamically, but I guess Crockford has primarily the real-world usage in his focus.

Answer 3

In dynamic languages, the check is always runtime. So in dynamic languages a class based inheritance is basically special case of protoptypal one where the objects used as prototypes are considered a special kind of animal, class objects.

Dynamic languages with class-based inheritance like perl, python or ruby, there are various semantic restrictions that prevent you from using arbitrary stuff as class. That is I think what they mean; there are always some hooks that actually allow using arbitrary prototypes in those languages, but they are beyond scope of "class-based constructs".

This relies on the fact that in dynamic languages a class is not a type in sense similar to how built-in types are. All objects are just associative arrays and the class only describes which keys are to be expected there.

In static languages however a prototype inheritance can't be used at all, because the compiler needs to know which members exist and thus needs the class to be a type while instances are just objects. So they inherently need two kinds of animals and prototypal inheritance is not possible at all.

You can implement an associative array in statically typed language and you can implement inheritance for it either "class" based or prototypal, but it won't be the real classes. All the instances will be of the same static type. That's what you are doing with your example.

So in 1 for dynamic languages they are right, but for static languages you are right. For 2 it makes no sense for static languages and for dynamic languages they are right for suitable definition of "class-based constructs" (which I would not consider a well defined construct).