Editing Self (programming language) (section)

== Prototype-based programming languages ==
{{main|Prototype-based programming}}
Traditional class-based OO languages are based on a deep-rooted duality:
#[[Class (object-oriented programming)|Classes]] define the basic qualities and behaviours of objects.
#[[Object (computer science)|Object instances]] are particular manifestations of a class.

For example, suppose objects of the <code>Vehicle</code> class have a ''name'' and the ability to perform various actions, such as ''drive to work'' and ''deliver construction materials''. <code>Bob's car</code> is a particular object (instance) of the class <code>Vehicle</code>, with the name "Bob's car". In theory one can then send a message to <code>Bob's car</code>, telling it to ''deliver construction materials''.

This example shows one of the problems with this approach: Bob's car, which happens to be a sports car, is not able to carry and deliver construction materials (in any meaningful sense), but this is a capability that <code>Vehicle</code>s are modelled to have. A more useful model arises from the use of [[subclass (set theory)|subclass]]ing to create specializations of <code>Vehicle</code>; for example <code>Sports Car</code> and <code>Flatbed Truck</code>. Only objects of the class <code>Flatbed Truck</code> need provide a mechanism to ''deliver construction materials''; sports cars, which are ill-suited to that sort of work, need only ''drive fast''. However, this deeper model requires more insight during design, insight that may only come to light as problems arise.

This issue is one of the motivating factors behind '''prototypes'''. Unless one can predict with certainty what qualities a set of objects and classes will have in the distant future, one cannot design a class hierarchy properly. All too often the program would eventually need added behaviours, and sections of the system would need to be re-designed (or [[Refactoring|refactored]]) to break out the objects in a different way.{{Citation needed|date=February 2007}} Experience with early OO languages like [[Smalltalk]] showed that this sort of issue came up again and again. Systems would tend to grow to a point and then become very rigid, as the basic classes deep below the programmer's code grew to be simply "wrong". Without some way to easily change the original class, serious problems could arise.{{Citation needed|date=February 2007}}

Dynamic languages such as Smalltalk allowed for this sort of change via well-known methods in the classes; by changing the class, the objects based on it would change their behaviour. However, such changes had to be done very carefully, as other objects based on the same class might be expecting this "wrong" behavior: "wrong" is often dependent on the context. (This is one form of the [[fragile base class problem]].) Further, in languages like [[C++]], where subclasses can be compiled separately from superclasses, a change to a superclass can actually break precompiled subclass methods. (This is another form of the fragile base class problem, and also one form of the [[fragile binary interface problem]].)

In Self, and other prototype-based languages, the duality between classes and object instances is eliminated.

Instead of having an "instance" of an object that is based on some "class", in Self one makes a copy of an existing object, and changes it. So <code>Bob's car</code> would be created by making a copy of an existing "Vehicle" object, and then adding the ''drive fast'' method, modelling the fact that it happens to be a [[Porsche 911]]. Basic objects that are used primarily to make copies are known as ''prototypes''. This technique is claimed to greatly simplify dynamism. If an existing object (or set of objects) proves to be an inadequate model, a programmer may simply create a modified object with the correct behavior, and use that instead. Code which uses the existing objects is not changed.