4

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?

4
  • Anything can be encoded in anything, even in brainf**k or x86 assembly as long as you're encoding it in Turing complete system (with the given limitations). The other direction (emulating classical inheritance in JS) is also a matter of ~ 10 lines in JavaScript. Aug 23, 2013 at 8:31
  • @BenjaminGruenbaum: Sorry, I meant to say that two languages being Turing-completeness is not enough to guarantee that one can replicate the operational semantics of the other.
    – isekaijin
    Aug 23, 2013 at 10:29
  • Talking about subsumpion, are there any prototype-based OOP languages that were implemented using other ones of their kind? Probably not.
    – Den
    Aug 23, 2013 at 10:51
  • @Den: The Self system (compiler, libraries, IDE, editor, browsers, even the graphics and mouse drivers) is written completely in Self. Only the original Self VM is written in C++, but there is another Self VM called Klein which is written in Self. There is also a Self VM written in JavaScript, I think. There is a JavaScript implementation written in Self, and there is a JavaScript implementation written in JavaScript. There are implementations of Io in JavaScript. Aug 24, 2013 at 2:39

3 Answers 3

5

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

2
  • The operational semantics of C++ member functions and a struct full of function pointers are completely different.
    – isekaijin
    Aug 23, 2013 at 10:26
  • 1
    @EduardoLeón: they are not completely different, since there is a big class of real-world problems you can solve with both. Try to see it from a more practical point of view.
    – Doc Brown
    Aug 23, 2013 at 10:43
3

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.

2

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

2
  • Syntactic issues aside (my use of object["member"] instead of object.member in the C++ implementation), why would 2 make no sense for static languages? (By the way object["member"] is also legal JavaScript.)
    – isekaijin
    Aug 23, 2013 at 7:59
  • @EduardoLeón: Because it would no longer be static. A statically typed language means that each class is a type defining which members exist. You can create a type for dynamically typed objects in statically typed language, that's what you are doing, but they are no longer statically typed as their static type is always the same.
    – Jan Hudec
    Aug 23, 2013 at 8:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.