Editing Prototype-based programming

{{Short description|Style of object-oriented programming in which inheritance is based on reusing objects}}
{{Distinguish|Prototype pattern|Software prototyping}}

'''Prototype-based programming''' is a style of [[object-oriented programming]] in which behavior reuse (known as [[inheritance (programming)|inheritance]]) is performed via a process of reusing existing [[object (programming)|object]]s that serve as [[prototype]]s. This model can also be known as ''prototypal'', ''prototype-oriented,'' ''classless'', or ''instance-based'' programming.

Prototype-based programming uses the process generalized objects, which can then be cloned and extended. Using fruit as an example, a "fruit" object would represent the properties and functionality of fruit in general. A "banana" object would be cloned from the "fruit" object and general properties specific to bananas would be appended. Each individual "banana" object would be cloned from the generic "banana" object. Compare to the [[Class-based programming|class-based]] paradigm, where a "fruit" ''class'' would be extended by a "banana" ''class''.

==History==

The first prototype-based [[programming language|programming languages]] were Director a.k.a. Ani (on top of [[MacLisp]]) (1976-1979), and contemporaneously and not independently, ThingLab (on top of [[Smalltalk]]) (1977-1981), respective PhD projects by Kenneth Michael Kahn at MIT and Alan Hamilton Borning at Stanford (but working with Alan Kay at Xerox PARC). Borning introduced the word "prototype" in this context in his 1981 paper in ''[[ACM Transactions on Programming Languages and Systems]] (TOPLAS)''. Note however, that these were both inspired by Winograd and Bobrow's [[KRL (programming language)|KRL]] by  (1975-1976), who introduced the words and concepts of "prototype" and (multiple) "inheritance" in the related context of "Knowledge Representation"—for data rather than programs as such—itself based on Minsky's 1974 concept of [[Frame_(artificial_intelligence)|Frames]]. The first prototype-based programming language with more than one implementer was probably [[T (programming language)|Yale T Scheme]] (1981-1984), though like Director and ThingLab initially, it just speaks of objects without classes. The language that made the name and notion of prototypes popular was [[Self (programming language)|Self]] (1985-1995), developed by [[David Ungar]] and Randall Smith to research topics in object-oriented language design.

Since the late 1990s, the classless paradigm has grown increasingly popular. Some current prototype-oriented languages are [[JavaScript]] (and other [[ECMAScript]] implementations such as [[JScript]] and [[Adobe Flash|Flash]]'s [[ActionScript]] 1.0), [[Lua (programming language)|Lua]], [[Cecil (programming language)|Cecil]], [[NewtonScript]], [[Io (programming language)|Io]], [[Ioke (programming language)|Ioke]], [[MOO (programming language)|MOO]], [[REBOL]] and [[AutoHotkey|AHK]].

Since the 2010s, a new generation of languages with pure functional prototypes has appeared, that reduce OOP to its very core: [[Jsonnet]] is a [[Type system#Dynamic type checking and runtime type information|dynamic]] [[Lazy evaluation|lazy]] [[Purely functional programming|pure functional]] language with a builtin prototype object system using [[mixin]] inheritance; [[Nix (package manager)#Implementation|Nix]] is a [[Type system#Dynamic type checking and runtime type information|dynamic]] [[Lazy evaluation|lazy]] [[Purely functional programming|pure functional]] language that builds an equivalent object system (Nix "extensions") in just two short function definitions (plus many other convenience functions). Both languages are used to define large distributed software configurations (Jsonnet being directly inspired by GCL, the Google Configuration Language, with which Google defines all its deployments, and has similar semantics though with dynamic binding of variables). Since then, other languages like [[Gerbil Scheme]] have implemented pure functional lazy prototype systems based on similar principles.

==Design and implementation==
Etymologically, a "prototype" means "first cast" ("cast" in the sense of being manufactured). A prototype is a concrete thing, from which other objects can be created by copying and modifying. For example, the [[International Prototype of the Kilogram]] is an actual object that really exists, from which new kilogram-objects can be created by copying. In comparison, a "class" is an abstract thing, in which objects can belong. For example, all kilogram-objects are in the class of KilogramObject, which might be a subclass of MetricObject, and so on.

Prototypal inheritance in JavaScript is described by [[Douglas Crockford]] as 
{{Quote
|You make prototype objects, and then … make new instances. Objects are mutable in JavaScript, so we can augment the new instances, giving them new fields and methods. These can then act as prototypes for even newer objects. We don't need classes to make lots of similar objects… Objects inherit from objects. What could be more object oriented than that?<ref>{{cite web|last=Crockford|first=Douglas|title=Prototypal Inheritance in JavaScript|url=http://crockford.com/javascript/prototypal.html|access-date=22 June 2021}}</ref>
}}

Advocates of prototype-based programming argue that it encourages 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 [[class (programming)|classes]].<ref name="Taivalsaari"/> Many prototype-based systems encourage the alteration of prototypes during [[Run time (program lifecycle phase)|run-time]], whereas only very few class-based object-oriented systems (such as the dynamic object-oriented system, [[Common Lisp]], [[Dylan (programming language)|Dylan]], [[Objective-C]], [[Perl]], [[Python (programming language)|Python]], [[Ruby (programming language)|Ruby]], or [[Smalltalk]]) allow classes to be altered during the execution of a program.

Almost all prototype-based systems are based on [[interpreted language|interpreted]] and [[dynamically typed]] languages. Systems based on [[statically typed]] languages are technically feasible, however. The Omega language discussed in ''Prototype-Based Programming''<ref>{{cite book | chapter = Section 2.8 | page = 177 | first = Günther | last = Blaschek | title = Omega: Statically Typed Prototypes }}</ref> 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 prototype-based languages there are no explicit classes. Objects inherit directly from other objects through a prototype property. The prototype property is called <code>prototype</code> in [[Self (programming language)|Self]] and [[JavaScript]], or <code>proto</code> in [[Io (programming language)|Io]]. There are two methods of constructing new objects: ''[[ex nihilo]]'' ("from nothing") object creation or through ''cloning'' an existing object. The former is supported through some form of object [[Literal (computer programming)|literal]], declarations where objects can be defined at runtime through special syntax such as <code>{...}</code> and passed directly to a variable. While most systems support a variety of cloning, ''ex nihilo'' object creation is not as prominent.<ref>{{cite book | chapter = Section 1.2 | page = 17 | first1 = Christophe | last1 = Dony | first2 = Jacques | last2 = Malenfan | first3 = Daniel | last3 = Bardou | chapter-url = http://www.lirmm.fr/~dony/postscript/proto-book.pdf | title = Classifying Prototype-based Programming Languages }}</ref>

In class-based languages, a new instance is constructed through a class's [[constructor (computer science)|constructor function]], a special function that reserves a block of memory for the object's members (properties and methods) and returns a reference to that block. An optional set of constructor [[parameter (computer science)|arguments]] can be passed to the function and are usually held in properties. The resulting instance will inherit all the methods and properties that were defined in the class, which acts as a kind of template from which similarly typed objects can be constructed.

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 exists a root object, often called ''Object'', which is set as the default prototype for all other objects created in run-time and which carries commonly needed methods such as a <code>toString()</code> function to return a description of the object as a string. One useful aspect of ''ex nihilo'' object creation is to ensure that a new object's slot (properties and methods) names do not have [[namespace]] conflicts with the top-level ''Object'' object. (In the [[JavaScript]] language, one can do this by using a null prototype, i.e. <code>Object.create(null)</code>.)

''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 (object-oriented programming)|delegation]]'' or ''[[resemblance (programing)|resemblance]]'') to its prototype, and changes in the prototype cause corresponding changes to be apparent in its clone. Other systems, such as the [[Forth (programming language)|Forth]]-like programming language [[Kevo (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.<ref name="Taivalsaari">{{cite book | chapter = Section 1.1 | first = Antero | last = Taivalsaari | title = Classes vs. Prototypes: Some Philosophical and Historical Observations | year = 1996 | pages = 44–50 | citeseerx = 10.1.1.56.4713 }}</ref>

<syntaxhighlight lang=JavaScript>
// Example of true prototypal inheritance style in JavaScript.

// Object creation using the literal object notation {}.
const foo = { name: "foo", one: 1, two: 2 };

// Another object.
const bar = { two: "two", three: 3 };

// Object.setPrototypeOf() is a method introduced in ECMAScript 2015.
// For the sake of simplicity, let us pretend that the following
// line works regardless of the engine used:
Object.setPrototypeOf(bar, foo); // foo is now the prototype of bar.

// If we try to access foo's properties from bar from now on, 
// we'll succeed. 
bar.one; // Resolves to 1.

// The child object's properties are also accessible.
bar.three; // Resolves to 3.

// Own properties shadow prototype properties.
bar.two; // Resolves to "two".
bar.name; // Unaffected, resolves to "foo".
foo.name; // Resolves to "foo".
</syntaxhighlight>

For another example:
<syntaxhighlight lang=JavaScript>
const foo = { one: 1, two: 2 };

// bar.[[prototype]] = foo
const bar = Object.create(foo);

bar.three = 3;

bar.one; // 1
bar.two; // 2
bar.three; // 3
</syntaxhighlight>

==Delegation==
In prototype-based languages that use ''delegation'', the language runtime is capable of [[dynamic dispatch|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, some prototype-based languages refer to both data and methods as "slots" or "members".{{Citation needed|reason=Sentence needs at least 1 citation. I've coded professionally in JS(all variants) & ActionScript for 4 years, and I've NEVER seen "slots" used this way in JS, and rarely in AS. E.g. see inconsistent/nonexistent usage in following: [http://www.google.com/#q=javascript+methods+properties+slots&hl=en&pws=0&biw=1247&bih=673&site=webhp&fp=528dfc887ad8eb4a&bav=on.2,or.r_gc.r_pw.,cf.osb&cad=b] & [http://www.google.com/#q=actionscript+methods+properties+slots&hl=en&pws=0&biw=1247&bih=673&site=webhp&fp=1&bav=on.2,or.r_gc.r_pw.,cf.osb&cad=b] . I'm calling 'Citation-needing', if not 'Dubious'.|date=January 2012}}

==Concatenation==
In ''concatenative'' prototyping - the approach implemented by the Kevo programming language - there are no visible pointers or links to the original prototype from which an object is cloned. The prototype (parent) object is copied rather than linked to and there is no delegation. As a result, changes to the prototype will not be reflected in cloned objects.<ref name=Taivalsaar>{{cite web | title = Simplifying JavaScript with Concatenation-Based Prototype Inheritance | author = Antero Taivalsaar | language = en | publisher = Tampere University of Technology | date = 2009 | url = http://lively.cs.tut.fi/publications/TR6-JavaScriptConcatenation-Taivalsaari.pdf | archive-url = https://web.archive.org/web/20110813004939/http://lively.cs.tut.fi/publications/TR6-JavaScriptConcatenation-Taivalsaari.pdf | archive-date = 2011-08-13 | quote = Kevo implemented a pure concatenation-based object model in which new objects were created by copying and the namespaces of all the objects were always fully self-contained. … Furthermore, Kevo had an internal ''clone family'' mechanism that made it possible to track the “genealogy” of changes among groups of objects, so that changes to individual objects could be propagated to other objects when necessary. | access-date = 2015-03-11}}</ref> Incidentally, the [[Cosmos (programming language)|Cosmos programming language]] achieves the same through the use of [[Persistent data structure|persistent data structures]].<ref>{{Cite web |title=Object-Oriented Programming |url=https://github.com/cosmos-lang/cosmos-lang.github.io/wiki/Object%E2%80%90Oriented-Programming |access-date=2023-09-04 |website=GitHub |language=en}}</ref>

The main conceptual difference under this arrangement is that changes made to a prototype object are not automatically propagated to clones. This may be seen as an advantage or disadvantage. (However, Kevo does provide additional primitives for publishing changes across sets of objects based on their similarity — so-called ''family resemblances'' or ''clone family'' mechanism<ref name=Taivalsaar /> — rather than through taxonomic origin, as is typical in the delegation model.) It is also sometimes claimed that delegation-based prototyping has an additional disadvantage in that changes to a child object may affect the later operation of the parent. However, this problem is not inherent to the delegation-based model and does not exist in delegation-based languages such as JavaScript, which ensure that changes to a child object are always recorded in the child object itself and never in parents (i.e. the child's value shadows the parent's value rather than changing the parent's value).

In simplistic implementations, concatenative prototyping will have faster member lookup than delegation-based prototyping (because there is no need to follow the chain of parent objects), but will conversely use more memory (because all slots are copied, rather than there being a single slot pointing to the parent object). More sophisticated implementations can avoid this problem, however, although trade-offs between speed and memory are required. For example, systems with concatenative prototyping can use a [[copy-on-write]] implementation to allow for behind-the-scenes data sharing — and such an approach is indeed followed by Kevo.<ref>{{cite journal | first = Antero | last = Taivalsaari | title = Kevo, a prototype-based object-oriented programming language based on concatenation and module operations | journal = Technical Report Report LACIR 92-02 | publisher = University of Victoria | year = 1992 }}</ref> Conversely, systems with delegation-based prototyping can use [[cache (computing)|caching]] to speed up data lookup.

==Criticism==
Advocates of class-based object models who criticize prototype-based systems often have concerns similar to the concerns that proponents of static type systems for programming languages have of dynamic type systems (see [[datatype]]). Usually, such concerns involve [[correctness (computer science)|correctness]], [[type safety|safety]], [[predictability]], [[algorithmic efficiency|efficiency]] and programmer unfamiliarity.

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.

Regarding efficiency, declaring classes simplifies many [[compiler]] optimizations that allow developing efficient method and instance-variable lookup. For the [[Self (programming language)|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.

A common criticism made against prototype-based languages is that the community of [[software developer]]s is unfamiliar with them, despite the popularity and market permeation of [[JavaScript]]. However, knowledge about prototype-based systems is increasing with the proliferation of [[JavaScript framework]]s and the complex use of JavaScript as the [[World Wide Web]] (Web) matures.<ref>{{Cite news|url=https://alistapart.com/article/prototypal-object-oriented-programming-using-javascript|title=Prototypal Object-Oriented Programming using JavaScript|date=2016-04-26|work=A List Apart|access-date=2018-10-21|language=en-US}}</ref>{{citation needed|date=March 2013}} ECMAScript 6 introduced classes as [[syntactic sugar]] over JavaScript's existing prototype-based inheritance, providing an alternative way to create objects and manage inheritance.<ref>{{cite web|title=Classes|url=https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes|website=JavaScript reference|publisher=Mozilla Developer Network|access-date=9 February 2016}}</ref>

==Languages supporting prototype-based programming==
{{div col}}
* [[Actor-Based Concurrent Language]] (ABCL): [[ABCL/1]], [[ABCL/R]], [[ABCL/R2]], [[ABCL/c plus|ABCL/c+]]
* [[Agora (programming language)|Agora]]
* [[AutoHotkey]]
* [[Cecil (programming language)|Cecil]] and [[Diesel (programming language)|Diesel]] of [[Craig Chambers]]
* [[ColdC]]
* [[COLA (software architecture)|COLA]]
* [[Common Lisp]]
* [http://www.cyan-lang.org/ Cyan]
* [[ECMAScript]]
** [[ActionScript]] 1.0, used by [[Adobe Flash]] and [[Adobe Flex]]
** [[ECMAScript for XML]] (E4X)
** [[JavaScript]]
** [[JScript]]
** [[TypeScript]]
* [[Io (programming language)|Io]]
* [[Ioke (programming language)|Ioke]]
* [[Jsonnet (programming language)|Jsonnet]]
* [[Logtalk]]
* [[LPC (programming language)|LPC]]
* [[Lua (programming language)|Lua]]
* [[M2000 Interpreter (programming language)|M2000]]
* [[Maple (software)|Maple]]
* [[MOO (programming language)|MOO]]
* [[Neko (programming language)|Neko]]
* [[NewtonScript]]
* [[Nim (programming language)|Nim]]
* [[Nix (package manager)|Nix]]
* [[Object Lisp]]
* [[Obliq]]
* [[Omega (programming language)|Omega]]
* [[OpenLaszlo]]
* [[Perl]], with the Class::Prototyped module
* [[Python (programming language)|Python]] with [https://github.com/airportyh/prototype.py prototype.py].
* [[R (programming language)|R]], with the proto package
* [[REBOL]]
* [[Red (programming language)|Red]]
* [[Ruby (programming language)|Ruby]]
* [[Self (programming language)|Self]]
* [[Seph (programming language)|Seph]]
* [[Slate (programming language)|Slate]]
* [[SmartFrog]]
* [[Snap! (programming language)|Snap!]]
* [[Etoys (programming language)|Etoys]]
* [[TADS]]
* [[Tcl]] with snit extension
* [[Umajin]]<ref>Proprietary scripting language. http://www.davidbrebner.com/?p=4 has some basic examples of use.</ref>
{{div col end}}

==See also==
* [[Class-based programming]] (contrast)
* [[Differential inheritance]]
* [[Programming paradigm]]

==References==
{{Reflist}}

==Further reading==
{{Wikibooks|Object oriented programming}}
* {{cite book|first=Martin|last=Abadi|author-link=Martin Abadi|author2=Luca Cardelli|author2-link=Luca Cardelli|title=A Theory of Objects|publisher=Springer-Verlag|year=1996|isbn=978-1-4612-6445-3}}
* [http://www.laputan.org/reflection/warfare.html Class Warfare: Classes vs. Prototypes], by Brian Foote.
* {{cite book|editor1-last=Noble|editor1-first=James|editor2-last=Taivalsaari|editor2-first=Antero |editor3-last=Moore|editor3-first=Ivan|year=1999|title=Prototype-Based Programming: Concepts, Languages and Applications|publisher=Springer-Verlag|isbn=981-4021-25-3}}
* [http://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/Delegation.html Using Prototypical Objects to Implement Shared Behavior in Object Oriented Systems], by Henry Lieberman, 1986.

{{Programming paradigms navbox}}
{{Types of programming languages}}

{{DEFAULTSORT:Prototype-Based Programming}}
[[Category:Prototype-based programming| ]]
[[Category:Object-oriented programming]]
[[Category:Programming paradigms]]
[[Category:Type theory]]