Prototype-based programming is a style of object-oriented programming in which classes are not present, and behavior reuse (known as inheritance in class-based languages) is performed via a process of cloning existing objects that serve as prototypes. This model can also be 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 classless programming style has recently grown increasingly popular, and has been adopted for the programming languages JavaScript, Cecil, NewtonScript, Io, MOO, REBOL, Lisaac and several others.
Comparison with class-based models
With class-based languages, the structure of objects is specified in programmer-defined types called classes. While classes define the type of data and functionality that objects will have, instances are "usable" objects based on the patterns of a particular class. In this model, classes act as collections of behavior (methods) and structure that are the same for all instances, whereas instances carry the objects' data. The role distinction is thus primarily based on a distinction between structure and behavior on the one hand, and state on the other.
Advocates of prototype-based programming often argue that class-based languages encourage a model of development that focuses first on the taxonomy and relationships between classes. In contrast, prototype-based programming is seen as encouraging the programmer to focus on the behavior of some set of examples and only later worry about classifying these objects into archetypal objects that are later used in a fashion similar to classes. As such, many prototype-based systems encourage the alteration of prototypes during runtime, whereas only 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.
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 [1] is an example of such a system, though according to Omega's website even Omega is not exclusively static but rather its "compiler may choose to use static binding where this is possible and may improve the efficiency of a program."
Object construction
In class-based languages a new instance is constructed through the class's constructor and an optional set of constructor arguments. The resulting instance is modeled on the layout and behavior dictated by the chosen class.
In prototype-based systems there are two methods of constructing new objects, through cloning of an existing object, and through ex nihilo ("from nothing") object creation. While most systems support a variety of cloning, ex nihilo object creation is not as prominent.[2]
Systems that 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 behaviors of new objects without referencing existing objects. In many prototype languages, there is often a basic Object prototype that 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 a newly constructed object's __proto__ property to null.)
Cloning refers to a process whereby a new object is constructed by copying the behavior 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.[3]
//Example of true prototypal inheritance style in JavaScript.
//"ex nihilo" object creation employing the literal object notation {}.
var foo = {one: 1, two: 2};
//another "ex nihilo" object.
var bar = {three: 3};
//Gecko and Webkit JavaScript engines can directly manipulate the internal prototype link.
//For the sake of simplicity, let's just pretend that the following line works regardless of the engine used:
bar.__proto__ = foo; // bar is now the child of foo.
//If we try to access foo's properties from bar from now on, we'll succeed.
bar.one //resolves to 1.
//The child objects properties are also accessible.
bar.three //resolves 3.
Delegation
In prototype-based languages that use delegation, the language runtime is capable of dispatching the correct method or finding the right piece of data simply by following a series of delegation pointers (from object to its prototype) until a match is found. All that is required to establish this behavior-sharing between objects is the delegation pointer. Unlike the relationship between class and instance in class-based object-oriented languages, the relationship between the prototype and its offshoots does not require that the child object have a memory or structural similarity to the prototype beyond this link. As such, the child object can continue to be modified and amended over time without rearranging the structure of its associated prototype as in class-based systems. It is also important to note that not only data but also methods can be added or changed. For this reason, most prototype-based languages refer to both data and methods as "slots".
Criticism
Advocates of class-based object models who criticize prototype-based systems often have concerns that could be seen as similar to those concerns that proponents of static type systems for programming languages have of dynamic type systems (see Datatype). Usually, such concerns involve: correctness, safety, predictability, and efficiency.
On the first three points, classes are often seen as analogous to types (in most statically typed object-oriented languages they serve that role) and are proposed to provide contractual guarantees to their instances, and to users of their instances, that they will behave in some given fashion.
On the last point, efficiency, the declaration of classes simplifies many compiler optimizations that allow developing efficient method and instance variable lookup. For the Self language, much development time was spent on developing, compiling, and interpreting techniques to improve the performance of prototype-based systems versus class-based systems. For example, the Lisaac compiler produces code almost as fast as C. Tests have been run with an 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[5].
The most common criticism made against prototype-based languages is that the community of software developers is not familiar with them, despite the popularity and market permeation of JavaScript. This knowledge level of prototype based systems seems to be changing with the proliferation of JavaScript frameworks and increases in the complex use of JavaScript as "Web 2.0" matures.
No comments:
Post a Comment