[bhk]

Can we ever get away from the misnomer of "prototype-based OO"?

In Self we have two ways of specialization:

  1. Prototypes
  2. Parents

Prototypes are objects that are "cloned" to create instances, a very simple and direct notion of inheritance. We create an object (a "prototype") with properties that apply to a larger set of objects, and then for each instance we copy (clone) it and then add or modify properties as necessary for the instance. Self had optimizations to deal with this so instances did not end up being very fat.

Parents are objects that other objects "inherit from". At run-time property lookups are delegated to a parent. The difference between a parent and a prototype is that changes to the prototype do NOT affect the derived instances. Changes to a parent DO affect the derived instances.

So, when I read about "class-based" versus "prototype-based" languages, I cringe. It is really "class-based" versus "parent-based". How did cloning get confused with run-time delegation?

Self introduced the notion of self-describing instances. That is the essential coolness. The simplifying notion.

http://www.selflanguage.org/_static/published/self-power.pdf

[endlessvoid94]

Agree. I'd also like to direct interested viewers to this other neat paper, entitled "Annotating objects for transport to other worlds": https://pdfs.semanticscholar.org/61f1/14dce92b7a49dbb8f981f2...

[cadillackness]

And to make it even worse, Object.create does parent-relationship, and Object.assign does the cloning(if you squint a little bit). Which seems like it should be flip-flopped, since "create" is closer to "cloning" than "assign" is. Even the es5 improvements ended up getting it wrong!

[DonbunEf7]

Relax already.

We say "prototype" to indicate an important feature of Self which its children (Python, JavaScript, etc.) inherited: Unlike classes, prototypes are open for modification. The precise mechanisms differ between the different languages in Self's family, but they all have that feature in common.

Compare and contrast with other Smalltalk children, like Java or E, where this isn't possible because classes are closed. (E doesn't have classes, but it has a similar property, in that object literal scripts are closed for modification.)

[jecel]

The problem is that there are two groups of languages that use "prototypes" and using the same word for slightly different concepts causes confusion.

In the original Lieberman paper[1] you created new objects that were empty and inherited from the prototype. Then you added local slots (name/value pairs) to the object for anything that was different from the prototype. Languages based on this concept often have two kinds of assignments: one that adds a new local slot and another that just replaces the value of the old slot (either local or inherited).

In Self, on the other hand, a prototype is a template for an object you want and you clone it to get a new object. Once it has been cloned, there is no longer any relation between the prototype and the new object and they evolve separately. These kind of languages tend to have only one way to assign values to slots.

Many languages that claimed to follow the Self model (like NewtonScript and Io) actually use the Lieberman model instead. In either case the prototypes are fully functioning examples of the object you want to create new instances of. So, unfortunately, it is natural that one word is used for both. But this results in very confusing discussions when someone is talking about a language with one model while thinking about the other model instead.

[1] http://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/De...

[goatlover]

The paper you linked to does mention prototypes as Self's alternative to classes.

Edit: Oh I see. Cloning is the alternative to instantiation. Parent slots are the alternative to classical inheritance.

[specialist]

It's class-based vs instance-based.