Prototype-based programming is a style of object-oriented programming in which classes are not present, and behaviour reuse (known as inheritance in class-based languages) is accomplished through a process of cloning existing objects which serve as prototypes. This model is also known as class-less, prototype-oriented, or instance-based programming.
The original (and most canonical) example of a prototype-based language is the programming language Self developed by David Ungar and Randall Smith. However, the class-less programming style has recently grown increasingly popular, and has been adopted for the programming languages JavaScript, Squeak when using the Viewer framework to manipulate Morphic components, Cecil, NewtonScript, Io, MOO, REBOL, Kevo, and several others.
Advocates of prototype-based programming often argue that class-based languages encourage a model of development which focus first on the taxonomy and relationships between classes. In contrast, prototype-based programming is seen as encouraging the programmer to focus on the behaviour of some set of examples and only later worry about classifying these objects into archetypal objects which are later used in a fashion similar to classes. As such, many prototype-based systems encourage the alteration of prototypes during runtime, whereas only a very few class-based object-oriented systems (such as the first dynamic object-oriented system, Smalltalk) allow classes to be altered during the execution of a program.
Prototype-based programming is often associated with particular schools of thought in cognitive psychology which emphasize prototypes or exemplars as key attributes of the learning process.
While the vast majority of prototype-based systems are based around interpreted and dynamically typed programming languages, it is important to point out that statically typed systems based around prototypes are technically feasible. The Omega programming language discussed in Prototype-Based Programming Section 2.8 (pg.177). Günther Blaschek, Omega: Statically Typed Prototypes is an example of such a system.
In prototype-based systems there are two methods of constructing new objects, through cloning of an existing object, and through ex nihilo ("from scratch") object creation. While most systems support a variety of cloning, ex nihilo object creation is not as prominent.Section 1.2 (pg.17). Chistophe Dony, Jacques Malenfan, Daniel Bardou, Classifying Prototype-based Programming Languages
Systems which support ex nihilo object creation allow new objects to be created from scratch without cloning from an existing prototype. Such systems provide a special syntax for specifying the properties and behaviours of new objects without referencing existing objects. In many prototype languages, there is often a basic Object prototype which carries commonly needed methods and is used as a master prototype for all other objects. One useful aspect of ex nihilo object creation is to ensure that a new object's slot names do not have namespace collisions with the top-level Object object. In the Mozilla JavaScript implementation, one can accomplish this by setting an object's __proto__ property to null.
Cloning refers to a process whereby a new object is constructed by copying the behaviour of an existing object (its prototype). The new object then carries all the qualities of the original. From this point on the new object can be modified. In some systems the resulting child object maintains an explicit link (via delegation or resemblance) to its prototype, and changes in the prototype cause corresponding changes to be apparent in its clone. Other systems, such as the Forth-like programming language Kevo, do not propagate change from the prototype in this fashion, and instead follow a more concatenative model where changes in cloned objects do not automatically propagate across descendants.Section 1.1 (pg.14). Antero Taivalsaari, Classes vs. Prototypes: Some Philosophical and Historical Observations
Advantages to this approach include the fact that object authors can alter the copy without worrying about side-effects across other children of the parent. A further advantage is that the computational cost of method lookup during dispatch is drastically reduced when compared to delegation, where an exhaustive search must be made of the entire delegation chain before failure to find a method or slot can be admitted.
Disadvantages to the concatenative approach include the organizational difficulty of propagating changes through the system; if a change occurs in a prototype, it is not immediately or automatically available on its clones. However, Kevo does provide additional primitives for publishing changes across sets of objects based on their similarity (so-called family resemblances) rather than through taxonomic origin, as is typical in the delegation model.
Another disadvantage is that, in the most naive implementations of this model, additional memory is wasted (versus the delegation model) on each clone for the parts that have stayed the same between prototype and clone. However, it is possible to provide concatenative behaviour to the programming while sharing implementation and data behind-the-scenes; such an approach is indeed followed by Kevo.Antero Taivalsaari. Kevo, a prototype-based object-oriented programming lnaguage based on concatenation and module operations. Technical Report Report LACIR 92-02, University of Victoria, 1992..
An alternative quasi-solution to the problem of clones interfering with the behaviour of the parent is to provide a means whereby the potential parent is flagged as being clonable or not. In MOO, this is achieved with the "f" flag. Only objects with the "f" flag can be cloned. In practice, this leads to certain objects serving as surrogate classes; their properties are kept constant to serve as initial values for their children. These children then tend to have the "f" flag not set.
In regard to the first three points, classes are often seen as analogous to types (and indeed, in most statically typed object-oriented languages they serve that role) and are proposed to provide contractual guarantees to their instances and users of their instances that they will behave in a given fashion.
On the last point, efficiency, the declaration of classes simplifies many compiler optimizations that allow the development of efficient method and instance variable lookup. In the case of the Self programming language, much development time has been spent on the development of compilation and interpretation techniques to improve the performance of prototype-based systems versus their class-based competitors. For example, Lisaac compiler produces code almost as fast as C. Tests have been run with a MPEG-2 codec written in Lisaac, copied from a C version. These tests show the Lisaac version is 1.9% slower than the C version with 37% fewer lines of code.
Finally, perhaps the most common criticism leveled against prototype-based languages is that the community of software developers is not familiar with them, despite the popularity and market permeation of JavaScript, (and in point of fact, the current work on a fourth edition of the ECMAScript standard is seeking to turn JavaScript into a class-based language). Further, as prototype-based systems are relatively novel, and few and far between, best practices for software development using them have not become widespread.
Programmation orientée prototype | 프로토타입 기반 프로그래밍 | Прототипное программирование | การเขียนโปรแกรมแบบโปรโตไทพ
This article is licensed under the GNU Free Documentation License.
It uses material from the
"Prototype-based programming".
Home Page • arts • business • computers • games • health • hospitals • home • kids & teens • news • physicians • recreation• reference • regional • science • shopping • society • sports • world