Prototype-based programming is a style and subset of object-oriented programming in which class (programming)es are not present, and behavior reuse (known as inheritance (programming) in class-based languages) is done by cloning (programming) existing object (programming)s which serve as prototypes for the new ones. It is also known as class-less , prototype-oriented , or instance-based programming.

The original (and canonical) example of a prototype based language is Self computer language, but the class-less programming style has recently grown increasingly popular, and has been adopted for the programming languages Cecil programming language, JavaScript, NewtonScript computer language, Io programming language, MOO programming language, REBOL, and several others.

=Incentive=

With class-based languages, object (computer science) come in two general types. Class (computer science) define the basic layout and functionality of objects, and instances are usable objects based on the patterns of a particular class. Programming in such a language typically consists of designing classes, and adding functionality to create various instances that store and manipulate data.

The classes are collections of code for the objects, which are the same for all instances, whereas the instances are collections of memory holding the objects data, which are what distinguishes them from each other (a concept known as state (computer science) ). This model works well with traditional Compilers, which basically write code and then have that code manipulate data.

One problem with class-based languages, in the opinion of proponents of prototype based programming, is that programs rarely remain static during development. As systems grow, their original class stuctures often become inadequate. The classes must be extended with more code, negating some of the benefits of object orientation. For some uses, it would be better if programs could change the behaviour of the underlying classes. In most languages, the classes are however fixed at compile time and can not be changed at Runtime.

=Prototypes and cloning=

Instead of data-containing instances and code-containing classes, prototype-based languages only have objects. A prototype system starts with at least one atomic object loaded, and new objects are created by cloning existing ones. Cloning an object creates an entirely new one that starts with the same default behaviours as its original.

Instead of having a pointer to a class, new objects contain a pointer to the object that created them. They are largely empty, and only start growing in memory when changed. This is different from class-based object-oriented languages, where each instance of a class usually sets aside a known amount of memory. Additional data can be added to any object at any point at runtime. Since objects grow as needed, anything can be added to them. In fact, every object in such a system tends to be different than every other, not only in the data themselves, but in what data are being recorded. 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 .

Although prototype based languages only need to start with one object, they typically provide a selection of basic objects for convenience. In general these objects tend to have method definitions only, relying on the programmer to add the data as needed. For instance, a Point object that can record positions in two dimensions might contain methods for adding and subtracting points, but not include the x and y definitions. The programmer would instead have to add these to each new copy.

This leads to some increased flexibility. Bugs in existing object methods can be fixed by sending the new code (in the form of blocks) into the appropriate slot . Similarly, any object can be turned into one that handles remote invocation by replacing methods in the same fashion. Class design is simplified, because the class definitions can be changed at any point in time, and within any application (one application can fix bugs in the objects it uses for itself, and the changes will not be visible to others).

=Pure prototypes=

Under pure prototyping, there are no pointers to the parent . The mother object is copied exactly, but given a different name (or reference). It can be compared to biological mitosis. Methods and attributes are simply duplicated as-is. The drawback is that memory is consumed for each copy for the parts that are the same. The advantage is that one can alter the copy without worrying about side-effects in the other children of the parent. Pure prototyping can also simplify implementation, assuming memory is not a scarce resource.

=Criticism=

From the point of view of proponents of statically typed programming languages, Correctness, safety, efficiency and predictability are more important than the minor increase in flexibility caused by ability to modify code at run-time.

A particularly good example of this is the extensive use of JavaScript to implement Mozilla Firefox s user interface and its extensions. The JavaScript running in the browser has higher security access than the JavaScript objects embedded in web pages, but often has to interact with untrusted objects. In a non-statically-typed language, it can be quite difficult to guarantee that you have the object you think you have and that the method you re calling does what you think it does. Calling a method that was replaced can cause untrusted code to run at a higher security level. This has resulted in many security bugs.

=Languages=

*Actor-Based Concurrent Language, ABCL: ABCL/1, ABCL/R, ABCL/R2, ABCL/c plus *Agora programming language *Cecil programming language *Cel programming language *ECMAScript a.k.a. ActionScript, DMDScript, JavaScript (first named Mocha, then LiveScript), JScript *Io programming language *Lua programming language *MOO programming language *NewtonScript *Obliq *REBOL *Self programming language *TADS

=See also=