Hubbry Logo
Prototype-based programmingPrototype-based programmingMain
Open search
Prototype-based programming
Community hub
Prototype-based programming
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Prototype-based programming
Prototype-based programming
Prototype-based programming
View on Wikipedia
from Wikipedia

Prototype-based programming is a style of object-oriented programming in which behavior reuse (known as inheritance) is performed via a process of reusing existing objects that serve as prototypes. 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 paradigm, where a "fruit" class would be extended by a "banana" class.

History

[edit]

The first prototype-based 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 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 Frames. The first prototype-based programming language with more than one implementer was probably 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 (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 Flash's ActionScript 1.0), Lua, Cecil, NewtonScript, Io, Ioke, MOO, REBOL and 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 dynamic lazy pure functional language with a builtin prototype object system using mixin inheritance; Nix is a dynamic lazy 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

[edit]

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

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?[1]

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 classes.[2] Many prototype-based systems encourage the alteration of prototypes during run-time, whereas only very few class-based object-oriented systems (such as the dynamic object-oriented system, Common Lisp, Dylan, Objective-C, Perl, Python, Ruby, or Smalltalk) allow classes to be altered during the execution of a program.

Almost all prototype-based systems are based on interpreted and dynamically typed languages. Systems based on statically typed languages are technically feasible, however. The Omega language discussed in Prototype-Based Programming[3] 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

[edit]

In prototype-based languages there are no explicit classes. Objects inherit directly from other objects through a prototype property. The prototype property is called prototype in Self and JavaScript, or proto in 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, declarations where objects can be defined at runtime through special syntax such as {...} and passed directly to a variable. While most systems support a variety of cloning, ex nihilo object creation is not as prominent.[4]

In class-based languages, a new instance is constructed through a class's 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 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 toString() 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. Object.create(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.[2] 

// 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".

For another example: 

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

Delegation

[edit]

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, some prototype-based languages refer to both data and methods as "slots" or "members".[citation needed]

Concatenation

[edit]

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.[5] Incidentally, the Cosmos programming language achieves the same through the use of persistent data structures.[6]

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[5] — 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.[7] Conversely, systems with delegation-based prototyping can use caching to speed up data lookup.

Criticism

[edit]

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, safety, predictability, 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 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 developers 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 frameworks and the complex use of JavaScript as the World Wide Web (Web) matures.[8][citation needed] ECMAScript 6 introduced classes as syntactic sugar over JavaScript's existing prototype-based inheritance, providing an alternative way to create objects and manage inheritance.[9]

Languages supporting prototype-based programming

[edit]

See also

[edit]

References

[edit]

Further reading

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Prototype-based programming

View on Grokipedia
from Grokipedia
Prototype-based programming is a style of in which objects are created and customized by cloning and extending existing objects called prototypes, rather than instantiating them from predefined classes. This paradigm emphasizes direct manipulation of concrete objects, unifying state and behavior within them, and relies on mechanisms like for inheritance, where method and property lookups traverse a chain of parent prototypes. Unlike class-based systems, it avoids abstract class definitions, promoting a simpler, more intuitive model focused on examples and incremental modifications. The approach emerged in the mid-1980s, drawing inspiration from frame languages for knowledge representation, such as KRL and FRL, and actor languages like Act 1 for distributed artificial intelligence. Key principles include object creation ex nihilo (from scratch), cloning to produce new instances, and differential extension to add or override properties without altering the original prototype. Message passing serves as the primary control mechanism, with delegation enabling dynamic resolution of behaviors by searching parent objects in a chain, often supporting features like explicit parent references for static binding. These elements facilitate programming by example, where developers work with tangible objects rather than abstract blueprints, making it particularly suitable for domains with few objects and frequent exceptions, such as statistical computing. Prototype-based languages vary in their interpretations of these principles, leading to diverse implementations. For instance, the language uses delegation with parent slots to enable seamless and dynamic reshaping of objects. Omega employs cloning and propagation, allowing changes in a prototype to affect its clones, and supports a single-rooted under a root object. Kevo introduces module operations for concatenation-based modifications, avoiding traditional delegation. NewtonScript, used in Apple's Newton platform, powered thousands of developers with its prototype cloning for handheld applications. Modern examples include JavaScript (ECMAScript), which underpins through prototype chains for object extension and sharing, despite later additions like class syntax for familiarity. Advantages of prototype-based programming include enhanced flexibility for runtime modifications, reduced conceptual overhead compared to classes, and support for rapid prototyping in dynamic environments. It excels in scenarios requiring one-of-a-kind objects or evolutionary design, such as user interfaces or exploratory data analysis, by allowing direct reuse and extension without rigid hierarchies. However, challenges arise in browsing complex prototype chains and ensuring structural consistency, as the model lacks the guarantees provided by class systems. Overall, it offers a concrete alternative to class-based paradigms, influencing languages and tools that prioritize adaptability and developer intuition.

Overview

Definition and Principles

Prototype-based programming is a style of in which objects serve as the primary units of abstraction and , with new objects created by or extending existing prototype objects rather than instantiating from predefined classes. In this , prototypes act as concrete exemplars that encapsulate both state and , allowing developers to build systems by starting from tangible examples and incrementally specializing them. Key principles include the unification of data and methods within objects, often referred to as slots, which store both values and executable code. is realized through references to , enabling an object to delegate unhandled requests to its prototype, thus promoting shared behavior without rigid hierarchies. The emphasizes dynamism, permitting runtime modifications to objects and their , which fosters exploratory and evolutionary development practices. Unlike traditional class-based , which relies on blueprints (classes) to define object templates, prototype-based approaches prioritize exemplars over abstractions, resulting in a simpler with fewer primitives and greater flexibility for ad-hoc extensions. This distinction supports programming by example, where developers can evolve objects directly from initial prototypes, reducing the overhead of class definitions and enabling more fluid adaptation to changing requirements. A basic illustration of object creation in this paradigm can be seen in the following pseudocode:

parent = { name: "Base" }; child = clone(parent); child.name = "Derived";

parent = { name: "Base" }; child = clone(parent); child.name = "Derived";

Here, the parent object serves as a prototype, and child is derived by cloning it before customization.

Comparison to Other Paradigms

Prototype-based programming differs fundamentally from class-based object-oriented programming (OOP) in its treatment of object creation and inheritance. In class-based systems, classes serve as static blueprints or templates that define the structure and behavior for instances, which are created through instantiation—a process that interprets class specifications to produce new objects. By contrast, prototype-based programming uses mutable prototype objects as starting points, where new objects are generated via cloning, allowing direct copying and immediate modification without predefined templates. This approach simplifies the conceptual model by eliminating the distinction between classes and instances, treating all entities uniformly as objects. Regarding inheritance, class-based OOP typically supports single inheritance through subclassing, enforcing a fixed hierarchy, whereas prototype-based systems employ delegation chains—dynamic parent pointers that enable multiple inheritance-like behavior by traversing a series of prototypes at runtime. Prototype-based programming shares some affinities with , particularly in implementations that emphasize higher-order functions and immutability to model . For instance, prototypes can be reduced to functional constructs like , where object instantiation and inheritance are achieved through pure functions such as fixed-point combinators for instantiation and composition operators for , avoiding mutation entirely. However, while prioritizes stateless functions and data transformation, prototype-based approaches introduce stateful objects that encapsulate both data and behavior, blending functional composition with object-oriented . In comparison to the actor model and procedural paradigms, prototype-based programming views objects as autonomous units capable of responding to requests through , which resembles in but lacks an explicit focus on concurrency or distributed systems. Delegation allows an object to forward unhandled requests to a parent , sharing dynamically, similar to how delegate messages to proxies for extensibility without direct state access. Unlike procedural paradigms, which organize code around sequences of function calls on global or passed data without inherent object boundaries, provide self-contained units that integrate state and methods, enabling via rather than function reuse alone. This object-centric structure supports emergent through delegation chains, contrasting with procedural modularity that relies on explicit procedure invocations. Key trade-offs in prototype-based programming include enhanced flexibility for and dynamic adaptation, as mutable prototypes allow one-off objects and runtime extensions without rigid hierarchies, facilitating exploratory development. However, this mutability can lead to tighter , as modifications to a shared prototype propagate to all clones, potentially complicating maintenance and increasing the risk of unintended side effects compared to the stronger encapsulation and structural consistency provided by class-based systems.

Historical Development

Origins in Early Languages

The conceptual foundations of prototype-based programming trace back to early innovations in symbolic computation and interactive systems during the 1950s and 1960s, particularly in the Lisp programming language. Lisp, developed between 1956 and 1958 at MIT, introduced property lists—associative structures attached to symbols (atoms) that stored arbitrary key-value pairs, enabling dynamic attachment of behaviors and data without predefined schemas. This mechanism served as a precursor to slot-based object representations, allowing flexible, runtime-modifiable entities in AI applications like the Advice Taker system. Complementing this, Lisp's dynamic typing, where type information is determined at runtime without declarations, facilitated experimental and extensible programming styles that influenced later object models by treating code and data uniformly. A pivotal advancement came in 1963 with Ivan Sutherland's system, an interactive graphics program implemented on the TX-2 computer at MIT. employed a master-instance model, where a "master" drawing defined reusable geometric entities, and "instances" were linked copies that inherited and shared properties from the master. Modifications to the master, such as altering a hexagon's shape, automatically propagated to all instances, enabling efficient creation of complex patterns like fish scales through topological ring structures. This approach pioneered interactive object manipulation via a , allowing users to create, position, scale, and rotate instances while preserving relational constraints, laying groundwork for reusable, mutable entities central to prototype concepts. In the 1970s, frame languages such as FRL (1974) and KRL (1975) introduced structured knowledge representation using frames with slots for properties and inheritance mechanisms, providing early models for prototype-like objects in artificial intelligence applications. Alan Kay's work on Smalltalk at Xerox PARC built on these ideas, envisioning objects as autonomous "morphs"—dynamic, biological-like entities that communicated via messages and hid internal state, inspired by Sketchpad's masters and Lisp's flexibility. Although Smalltalk adopted a class-based structure, Kay's emphasis on objects as universal, self-contained modules with late binding and recursive design fostered prototype-like thinking, promoting incremental evolution over rigid hierarchies. Concurrently, MIT's Lisp Machines introduced the Flavors system around 1979, an object-oriented extension to Lisp that supported message passing and flavor mixing—combining reusable components to inherit methods and variables dynamically, akin to delegation. Flavors bridged class-based and prototype paradigms by enabling modular, shared behavior without strict inheritance trees, influencing AI and simulation applications. These pre-1980s developments established core ideas of mutability, , and reuse.

Key Innovations and Milestones

One of the pivotal advancements in prototype-based programming occurred in 1986 with the development of the language by David Ungar and Randall B. Smith at Xerox PARC. introduced a pure prototype-based approach, eliminating classes entirely in favor of direct object and , which simplified object-oriented design by treating all objects uniformly as prototypes. A key innovation was the incorporation of mirrors, specialized objects enabling deep and reflection on an object's structure and behavior, facilitating powerful capabilities. Building on these foundations, the Io language emerged in 2002, created by Steve Dekorte to prioritize extreme simplicity and expressiveness in a prototype-based system. Io integrated actor-model concurrency primitives, allowing seamless message-passing for distributed and parallel computation while maintaining a minimal syntax where all values are objects derived through differential inheritance and cloning. This design emphasized embeddability and , influencing subsequent languages by demonstrating how prototype mechanisms could support actor-like behaviors without compromising core simplicity. The paradigm gained widespread adoption through , invented by in 1995 for , which implemented prototypes as its underlying inheritance mechanism through constructor functions and prototype chains. This choice enabled dynamic object creation and delegation in web browsers, popularizing prototype-based programming in client-side development and laying the groundwork for its dominance in interactive web applications. A significant milestone arrived with ECMAScript 2015 (ES6), which introduced class syntax as syntactic sugar over JavaScript's prototype chain, streamlining common patterns while preserving the underlying delegation model. This update enhanced developer productivity without altering the core prototype semantics, facilitating broader integration into modern web frameworks. Concurrently, the V8 JavaScript engine, developed by Google and released in 2008, advanced prototype handling through optimizations like inline caching and fast property access, dramatically improving runtime performance for prototype-based code in browsers and Node.js environments. Post-2020 developments have further embedded prototype-based principles in emerging paradigms, particularly , where JavaScript's prototype model powers scalable, event-driven functions in platforms like and . These evolutions underscore the paradigm's adaptability to distributed, resource-efficient architectures.

Core Mechanisms

Prototypes and Object Structure

In prototype-based programming, objects serve as the fundamental units, each consisting of a collection of slots that store both (instance variables) and methods (). These slots are named key-value pairs, where the values can be primitive , other objects, or executable code, unifying state and operations within the same . Additionally, every object includes a dedicated prototype slot, often implemented as an internal such as a pointer, which links to another object acting as its . This design eliminates the need for separate class definitions, allowing objects to directly embody both their own properties and inherited ones through this linkage. Prototypes function as exemplars or templates within this , providing a concrete basis for creating new objects either by to produce customized variants or by direct to share behavior across instances. In languages like , a object holds shared slots for common methods and data, which clones inherit initially but can override, thereby promoting without abstract class hierarchies. This approach supports the creation of unique, one-off objects tailored for specific needs, as the prototype itself is a fully functional object rather than a mere blueprint. The resulting object graph forms a network of , illustrable as:

objectA = { slot1: "value1", method1: function() { /* [code](/page/Code) */ }, __proto__: prototypeB } prototypeB = { sharedMethod: function() { /* shared [code](/page/Code) */ }, __proto__: null // or another prototype }

objectA = { slot1: "value1", method1: function() { /* [code](/page/Code) */ }, __proto__: prototypeB } prototypeB = { sharedMethod: function() { /* shared [code](/page/Code) */ }, __proto__: null // or another prototype }

Here, objectA references its own slots and delegates unresolved accesses to prototypeB. A distinguishing feature of this model is the mutability of both objects and prototypes, permitting runtime modifications to slots—such as adding, updating, or removing —which propagate live updates to dependent structures if shared. In , for instance, can be dynamically altered unless protected by attributes like non-writable or non-configurable flags, enabling flexible evolution of object behavior during execution. Unlike class-based systems, where prototypes are often treated as metadata, prototypes here are first-class citizens: they are themselves objects that can be manipulated, passed as arguments, or returned from functions, fostering a uniform treatment of all entities in the system. This structural foundation facilitates , where property lookups traverse the prototype chain to resolve behaviors dynamically.

Delegation and Inheritance

In prototype-based programming, delegation serves as the primary mechanism for achieving inheritance-like behavior by enabling objects to forward messages to their prototypes when the requested method or attribute is not found locally. During method lookup, the system begins with the receiver object and traverses the prototype chain—typically a parent pointer or delegation link—passing the message to the next object in the chain until the method is resolved or the chain terminates at null, at which point an error is raised. This process allows for dynamic sharing of behavior without requiring predefined classes, as each delegation occurs on a per-message basis rather than through a static hierarchy. Prototype chains support runtime modifications, such as inserting or removing links, which enables flexible reconfiguration of relationships during program execution. For instance, an object can reassign its parent pointer to a different , instantly altering the behavior available to it and its dependents, or multiple paths can be established to simulate more complex sharing patterns. This mutability contrasts with fixed structures in other paradigms and facilitates exploratory programming where objects evolve incrementally. Compared to classical in class-based languages, provides a shallower form of , evaluating the chain anew for each rather than relying on a compile-time fixed that binds all methods uniformly. This per- resolution avoids issues like the problem in , as the linear traversal ensures a deterministic order without needing resolution rules for conflicting superclasses, though it may lead to less predictable outcomes in deeply nested chains. thus emphasizes explicit, runtime-defined relationships over implicit, structural ones. A simple pseudocode representation of delegation resolution might appear as follows:

function resolveMethod(obj, methodName): if obj.hasOwnMethod(methodName): return obj.getMethod(methodName) else if obj.proto != null: return resolveMethod(obj.proto, methodName) else: raise MethodNotFoundError

function resolveMethod(obj, methodName): if obj.hasOwnMethod(methodName): return obj.getMethod(methodName) else if obj.proto != null: return resolveMethod(obj.proto, methodName) else: raise MethodNotFoundError

This recursive traversal illustrates the chain-following logic central to . In advanced implementations like the language, mirrors extend to support by providing reflective access to an object's own structure, allowing methods to delegate to updated versions of themselves during execution for dynamic behavior adaptation.

Object Creation and Manipulation

Cloning and Mutation

In prototype-based programming, cloning serves as the fundamental mechanism for object creation, where a new object is produced by copying an existing . This process typically involves a shallow copy, which duplicates the prototype's slots and their immediate values while preserving references to shared nested objects or structures for efficiency. Deep , which recursively copies all nested elements, is generally avoided due to its computational expense and limited benefits in most scenarios. Following cloning, allows the new object to be customized without altering the original . Developers can add new slots, override existing ones, or modify values directly on the clone, enabling tailored behavior while leveraging the 's shared methods and data. For instance, in a -like syntax, a new object can be from a and then as follows:

javascript

var proto = { x: 10, getX: function() { return this.x; } }; var clone = Object.create(proto); clone.x = [20](/page/2point0); // Mutates the clone's own slot, shadowing the prototype's clone.y = [30](/page/-30-); // Adds a new slot to the clone

var proto = { x: 10, getX: function() { return this.x; } }; var clone = Object.create(proto); clone.x = [20](/page/2point0); // Mutates the clone's own slot, shadowing the prototype's clone.y = [30](/page/-30-); // Adds a new slot to the clone

This approach supports rapid iteration and specialization, as seen in languages like , where the clone message initiates the copy, followed by slot assignments. The advantages of cloning and include enhanced flexibility for dynamic object and reduced boilerplate compared to class instantiation, fostering intuitive prototyping. However, shallow cloning risks unintended sharing of mutable nested structures, potentially leading to side effects if one clone modifies a shared reference. To mitigate such issues, modern prototype-based systems incorporate immutability variants, often drawing on persistent data structures that enable non-destructive updates through structural sharing. Cloned objects typically retain links to their prototypes for behavior lookup, as detailed in core mechanisms.

Concatenation of Prototypes

In prototype-based programming, refers to the process of merging properties and methods from multiple source prototypes into a new, self-contained object, typically through shallow copying and resolution of conflicts based on the order of concatenation or predefined rules. This mechanism enables compositional inheritance by directly combining object interfaces without relying on dynamic lookup chains. Implementation of concatenation often involves linear merging, where properties from later prototypes override those from earlier ones, or tree-based structures for more complex compositions. In the Kevo language, for instance, this is achieved via operations followed by slot additions (e.g., an "ADDS" mechanism) and propagation rules to apply changes across related objects, supporting through multicopy operations. Such approaches mimic mixin-like behavior, allowing developers to compose objects from reusable components without deep hierarchical dependencies. The primary benefits of concatenation include enabling flexible, compositional that avoids the limitations of long delegation chains, such as shared state mutations or lookup overhead; it also promotes self-sufficient objects that are easier to reason about and optimize statically. By supporting traits or role-based extensions, concatenation facilitates modular designs where objects can incorporate behaviors from multiple sources, enhancing reusability in scenarios requiring ad-hoc combinations. For example, in inspired by concatenative systems, a new object can be created as follows:

newObj = concat(protoA, protoB);

newObj = concat(protoA, protoB);

Here, newObj inherits all slots from protoB first, with protoA's slots overriding conflicts, such as methods or data ; unresolved lookups may still delegate to a base if specified. addresses key limitations of pure in complex compositions by producing independent objects, though it remains less common in mainstream languages like —where dominates—and is more prevalent in research-oriented systems such as Kevo.

Implementation Considerations

Design Strategies

In prototype-based programming, modularity is achieved by treating prototypes as self-contained, reusable components that encapsulate both data and behavior, thereby promoting code reuse without relying on global state. This approach allows developers to compose systems from independent prototype modules, where each prototype serves as a building block that can be cloned or delegated to without introducing shared mutable state across the entire program. By avoiding global namespaces, prototype-based designs reduce coupling and enhance maintainability, as modifications to one prototype do not inadvertently affect unrelated parts of the system. Introspection plays a central role in prototype-based systems, enabling runtime querying and modification of an object's structure through reflective mechanisms such as mirrors. These built-in reflection capabilities allow programmers to inspect slots, prototypes, and delegation chains dynamically, facilitating metaprogramming tasks like serialization or debugging without predefined class hierarchies. For instance, a mirror object can represent the internal state of a prototype, providing methods to enumerate properties or alter behaviors on the fly, which supports exploratory and adaptive programming paradigms. Error handling in prototype-based designs often leverages delegation chains with fallback mechanisms, where unresolved messages propagate to parent prototypes containing default methods or null behaviors. This ensures graceful degradation; if a slot is missing in the current object, the system delegates to a root prototype with generic handlers, such as error-throwing or no-op functions, preventing abrupt failures. Designers typically include a universal fallback prototype at the chain's end to catch and manage exceptions uniformly across the structure. Best practices in prototype-based programming emphasize shallow cloning to create new objects efficiently, as it copies only the immediate slots while preserving the shared prototype link for , thereby minimizing memory overhead and maintaining delegation integrity. Deep cloning, which recursively copies the entire chain, is reserved for cases requiring full isolation but can lead to performance bottlenecks and unintended duplications. of prototypes—merging multiple sources into a single object—should be used sparingly to avoid slot name conflicts, where overlapping properties might override behaviors unexpectedly; instead, favor for composition to keep structures modular and predictable. Security designs in prototype-based systems, particularly in web contexts, focus on sandboxing mutable prototypes to mitigate risks like prototype pollution, where attackers inject malicious properties via shared chains. Browser standards incorporate features such as Object.freeze() and Proxy objects to create immutable or trapped prototypes within isolated realms, preventing unauthorized mutations during delegation. These features were introduced in 2015 (ES6). For web applications, sandboxing involves sealing prototypes in worker threads or iframes with strict Content Security Policies (CSP), ensuring that untrusted code cannot alter global object behaviors while adhering to ECMAScript specifications for secure introspection.

Performance and Optimization

Prototype-based systems often incur performance overhead from dynamic property and method lookups along delegation chains, which require traversing the hierarchy at runtime until a matching definition is found, unlike the direct pointer access provided by virtual tables (vtables) in class-based languages. This traversal can degrade dispatch speed, particularly with longer chains, leading to measurable slowdowns in uncached scenarios; for instance, JavaScript engines observe no penalty for short chains but performance degradation beyond a certain threshold. itself serves as a primary bottleneck in these lookups, as each unresolved access forwards the request up the chain, amplifying latency without optimizations. To address this, modern implementations employ inline caching (IC), a technique that speculatively caches the location of properties or methods based on prior access patterns, enabling near-direct dispatch on cache hits. In the V8 JavaScript engine, IC is pivotal for optimizing prototype-based property access, reducing startup times and improving overall execution by reusing compilation artifacts across invocations. Complementing IC, hidden classes (or shapes) represent object structures internally, allowing engines to predict and inline offsets for properties, mimicking static typing efficiency; this shape-based optimization has been refined through profile-guided offline adjustments to minimize memory overhead while boosting runtime performance in embedded JavaScript virtual machines. Memory management in prototype-based languages benefits from shared prototypes, which avoid duplicating behavior across instances and thus reduce overall allocation footprint compared to per-object storage in naive designs. However, this sharing introduces challenges for garbage collection, as bidirectional references between objects and prototypes can form cycles, necessitating tracing collectors that carefully track to prevent leaks or premature reclamation; implementations like those in the language demonstrate that with incremental mark-sweep collectors, these systems achieve efficient reclamation without excessive pause times. Benchmark studies indicate that prototype-based approaches are competitive or superior in highly dynamic scenarios, such as rapid object and extension, where flexibility outweighs lookup costs post-optimization, but they can incur higher overhead in static, predictable workloads dominated by fixed hierarchies compared to class-based counterparts. Recent advances in just-in-time () compilation, particularly for targets post-2020, have narrowed this gap by enabling feedback-directed optimizations for prototype-like in cross-language runtimes, achieving 3-5x speedups in JavaScript-to-Wasm compilation pipelines through ahead-of-time shape inference and reduced interpretation overhead.

Languages and Examples

Pure Prototype-Based Languages

Pure prototype-based languages are programming languages where the core object model revolves exclusively around prototypes, eschewing classes entirely in favor of direct , , and for and . These languages emphasize simplicity and uniformity, treating all entities as objects that can be dynamically extended or modified without predefined structures. , Io, and Lisaac represent key examples, each advancing the through distinct syntactic and semantic innovations while remaining dedicated to prototypal principles. Self, developed in 1986 by David Ungar and Randall B. Smith at Xerox PARC, is a dynamic object-oriented language centered on , slots (key-value pairs for attributes and methods), and for behavior sharing. In Self, objects are collections of slots, and new objects are created by an existing , which copies its slots while allowing overrides. occurs via a special parent slot, enabling an object to forward unresolved messages to its , thus implementing without classes. For instance, a basic example defines a trait with methods, then clones it for specific instances:

traits point = (| x: 0.0. y: 0.0. distanceTo: p = ((x - p x) squared + (y - p y) squared) sqrt. |). point = traits point clone. p1 = point clone set x(3.0) set y(4.0). p2 = point clone set x(0.0) set y(0.0). p1 distanceTo: p2 // Delegates to traits point via [parent](/page/Parent)

traits point = (| x: 0.0. y: 0.0. distanceTo: p = ((x - p x) squared + (y - p y) squared) sqrt. |). point = traits point clone. p1 = point clone set x(3.0) set y(4.0). p2 = point clone set x(0.0) set y(0.0). p1 distanceTo: p2 // Delegates to traits point via [parent](/page/Parent)

This syntax highlights Self's exploratory focus, where slots can be added or modified at runtime, influencing subsequent research in dynamic languages despite limited commercial adoption. Io, created by Steve Dekorte in 2002, is a pure object-oriented language inspired by Smalltalk and , featuring prototype-based inheritance through cloning and a uniform message-passing model where all operations are dynamic messages sent between objects. Every value is an object, and the root Lobby serves as the global namespace and default prototype, from which all objects delegate via slots. Objects support actor-like behavior through coroutines and asynchronous messaging, enabling concurrent prototypes that process messages independently. An example of an actor-like prototype in Io creates a clonable object that handles asynchronous tasks:

Counter := Object clone do( value := 0 increment := method(v, value = value + v; value println) asyncIncrement := method(v, (@increment)(v)) // Coroutine for actor-like async ) counter1 := Counter clone counter1 @@increment(5) // Async send, delegates to Lobby if needed

Counter := Object clone do( value := 0 increment := method(v, value = value + v; value println) asyncIncrement := method(v, (@increment)(v)) // Coroutine for actor-like async ) counter1 := Counter clone counter1 @@increment(5) // Async send, delegates to Lobby if needed

Io's minimal syntax and embeddability have made it suitable for scripting and prototyping, though it remains primarily a research and educational tool. Lisaac, introduced by Benoit Sonntag in the late for the operating system, is a compiled -based language that introduces static typing and design-by-contract while supporting concatenation for composing multiple prototypes into a new one, allowing flexible beyond simple . Unlike purely dynamic languages, Lisaac enforces type contracts at for reliability in , yet retains prototypal cloning and slot manipulation. Concatenation in Lisaac merges prototypes' slots, resolving conflicts via overrides, as in defining a base prototype and concatenating extensions for enhanced objects. Its syntax blends Eiffel-like contracts with Self-inspired prototypes, enabling high-performance executables comparable to . The Omega release in added native and unlimited arithmetic, enhancing its utility for modern applications. These languages continue to influence academic research and niche educational contexts, demonstrating the viability of pure prototypal models, though none have seen widespread industrial adoption as of 2025, with development focused on maintenance and targeted enhancements rather than major paradigm shifts.

Languages with Prototype Features

JavaScript exemplifies a widely adopted language with integrated prototype-based features, forming the foundation of its object-oriented model. Every object maintains an internal link to a prototype object via the __proto__ property, enabling property and method inheritance through a chain that resolves missing attributes by traversing prototypes until reaching null. The Object.create() method facilitates explicit prototype assignment, allowing developers to construct objects with custom inheritance hierarchies without relying on constructors. ES6 introduced class syntax as syntactic sugar atop this prototypal system, streamlining declarations while preserving the underlying delegation mechanism. JavaScript's prototype features underpin its ubiquity in web development, where it serves as the client-side language for 98.9% of all websites as of late 2025. Practical manipulation of the prototype chain in often involves creating objects and extending them dynamically, as shown below:

javascript

const animal = { eats: true, type: 'mammal' }; const rabbit = Object.create(animal); rabbit.jumps = true; // Instance-specific property console.log(rabbit.eats); // true, delegated to prototype console.log(rabbit.type); // 'mammal', inherited via chain rabbit.__proto__ = { sleeps: true }; // Reassign prototype for further delegation console.log(rabbit.sleeps); // true

const animal = { eats: true, type: 'mammal' }; const rabbit = Object.create(animal); rabbit.jumps = true; // Instance-specific property console.log(rabbit.eats); // true, delegated to prototype console.log(rabbit.type); // 'mammal', inherited via chain rabbit.__proto__ = { sleeps: true }; // Reassign prototype for further delegation console.log(rabbit.sleeps); // true

This example demonstrates inheritance resolution and prototype reassignment, common in dynamic web applications for sharing behavior across instances. Lua incorporates prototype elements through its versatile table construct, which functions as both and object . Tables can serve as shared prototypes for instances, with methods defined within them to encapsulate . Metatables provide by linking a table to a prototype table via the __index metamethod, allowing unresolved attribute lookups to fall back to the prototype—mimicking prototypal . This approach enables flexible object creation and extension without rigid class definitions, supporting Lua's use in embedded systems and game scripting. A typical Lua example illustrates metatable-based delegation for prototype-like inheritance:

lua

Account = { balance = 0 } function Account:deposit(v) self.balance = self.balance + v end local mt = { __index = Account } -- Metatable for delegation local a1 = { balance = 0 } setmetatable(a1, mt) a1:deposit(100) -- Calls Account:deposit via __index print(a1.balance) -- 100

Account = { balance = 0 } function Account:deposit(v) self.balance = self.balance + v end local mt = { __index = Account } -- Metatable for delegation local a1 = { balance = 0 } setmetatable(a1, mt) a1:deposit(100) -- Calls Account:deposit via __index print(a1.balance) -- 100

Here, a1 delegates the deposit method to the Account prototype, exemplifying metamethods for runtime behavior customization. ActionScript, developed for Adobe Flash, integrated prototype-based inheritance in its initial versions (ActionScript 1.0 and 2.0), where objects directly extended prototypes for behavior reuse in interactive multimedia. This model supported of web animations and applications, influencing early client-side scripting paradigms before Flash's in 2020. In ActionScript 3.0, prototypes remained an alternative to class-based , retaining utility for dynamic object manipulation in legacy Flash projects. Its prototype features were instrumental in shaping web interactivity standards, even as the platform faded. Among other languages, Ruby's open classes enable prototype-like extensibility by allowing runtime addition or modification of methods to existing classes, fostering dynamic behavior akin to prototype mutation without recompilation. This openness supports patterns that echo prototypal flexibility in Ruby's primarily class-based system. Emerging JavaScript runtimes in 2025, such as Deno and , enhance prototype ergonomics by optimizing execution speed and integrating seamless tooling for prototype chain operations, making prototypal patterns more efficient in modern web and server environments. These runtimes build on 's core without altering its prototype model, yet improve developer workflows for , , and optimization in high-throughput applications.

Evaluation

Advantages

Prototype-based programming offers significant flexibility, particularly in environments requiring runtime modifications and agile development practices. By allowing objects to be cloned and altered dynamically without predefined class structures, it enables developers to extend and adapt code , making it well-suited for iterative prototyping and rapid experimentation. This approach supports the creation of unique, one-of-a-kind objects with custom behaviors, reducing the rigidity of traditional hierarchies and facilitating seamless integration of new features during development. The paradigm's simplicity stems from its elimination of classes and the associated instance distinctions, presenting a unified model where all objects inherit directly from prototypes via a single "inherits from" relationship. This reduces cognitive overhead and the , as programmers work with concrete examples rather than abstract blueprints, akin to modifying tangible entities rather than drafting specifications. Furthermore, it avoids the regress problem inherent in class-based systems, where objects can be self-sufficient without infinite layers of meta-abstractions. Reusability is enhanced through and mechanisms, which allow shared behavior to be inherited and customized incrementally without duplicating code. Prototypes serve as reusable defaults that objects can and override selectively, promoting efficient code extension and . In domains like user interfaces, this enables the natural creation and modification of specialized objects, overcoming memory constraints by loading prototypes on demand and expanding only as needed. As an enabler of innovation, prototype-based programming fosters experimental features such as , where changes to running systems can be observed immediately, drawing from environments influenced by Smalltalk and realized in languages like . This tangible, interactive style unifies objects, procedures, and closures, providing a more expressive framework for exploring novel computational models.

Criticisms and Limitations

One significant limitation of prototype-based programming is the risk of prototype corruption, where modifications to a shared prototype inadvertently affect all objects derived from it, potentially leading to runtime errors or crashes across the system. This issue arises due to the inherent mutability of prototypes, amplifying problems akin to the fragile base class problem in class-based systems, as changes propagate through delegation chains without clear boundaries. In languages like and Kevo, dynamic alterations to a prototype's interface can cause unpredictable behavior, making it challenging to maintain consistent object states in evolving codebases. Debugging in prototype-based systems is complicated by long delegation chains and the absence of fixed structures, as method lookups traverse dynamic links at runtime, obscuring and error origins. The lack of private slots in many implementations, such as NewtonScript, exposes internal details, enabling accidental or overrides that complicate tracing issues. Furthermore, the dynamic prohibits effective static and , as and object mutability prevent compile-time verification of interfaces or types, increasing reliance on runtime testing. Performance drawbacks stem from dynamic dispatch and slot lookups, which incur overhead in large systems compared to class-based static binding, as each object's unique structure resists optimization. In scaled applications, excessive delegation can create complex interdependencies, slowing execution and complicating optimization efforts despite mitigations like monomorphic caching in some languages. Maintenance challenges are exacerbated by the ad hoc nature of prototype creation and modification, lacking the enforced hierarchies of class-based paradigms, which can lead to unstructured code unsuitable for industrial-scale development. Mutability further risks unintended side effects during refactoring, as explicit prototype instantiation at program start requires careful management to avoid corruption. Adoption barriers persist for developers accustomed to class-based languages, as the paradigm's emphasis on concrete objects over abstract templates demands a shift in mental models, often resulting in initial confusion with semantics. Early prototype-based languages faced limited IDE support for prototype chains, hindering refactoring and visualization. However, as of 2025, modern tools such as , WebStorm, and provide advanced features for debugging, visualizing prototype chains, and static analysis, significantly improving usability in contexts and narrowing the gap with class-based systems. As of 2025, AI-powered tools like further enhance productivity in prototype-based development by suggesting dynamic object extensions.

References

  1. https://www.lirmm.fr/~dony/postscript/proto-book.pdf
  2. https://dl.acm.org/doi/pdf/10.1145/191081.191101
  3. https://ssw.jku.at/Teaching/Lectures/POPL/OOPwPT.pdf
  4. https://www.researchgate.net/publication/229087107_Prototype-Based_Programming_in_Statistical_Computation
  5. https://dl.acm.org/doi/pdf/10.1145/217839.217844
  6. https://bibliography.selflanguage.org/_static/self-power.pdf
  7. https://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/Delegation.html
  8. http://webyrd.net/scheme_workshop_2021/scheme2021-final91.pdf
  9. https://web.media.mit.edu/~lieber/Lieberary/OOP/Act-1/Concurrent-OOP-in-Act-1.html
  10. http://jmc.stanford.edu/articles/lisp/lisp.pdf
  11. https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-574.pdf
  12. https://dl.acm.org/doi/10.1145/361227.361244
  13. https://worrydream.com/EarlyHistoryOfSmalltalk/
  14. https://apps.dtic.mil/sti/tr/pdf/ADA095523.pdf
  15. https://www.selflanguage.org/
  16. https://handbook.selflanguage.org/2024.1/
  17. https://handbook.selflanguage.org/2024.1/progguid.html
  18. https://iolanguage.org/guide/guide.html
  19. https://blog.thesoftwarecraft.com/2013/08/week-2-io.html
  20. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Working_with_objects
  21. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Inheritance_and_the_prototype_chain
  22. https://babeljs.io/docs/learn/
  23. https://v8.dev/blog/fast-properties
  24. https://tc39.es/ecma262/#sec-object-type
  25. https://tc39.es/ecma262/#sec-property-attributes
  26. https://dl.acm.org/doi/10.1145/38765.38820
  27. https://www.researchgate.net/publication/251175970_Inheritance_and_Delegation
  28. https://bracha.org/mirrors.pdf
  29. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/create
  30. https://dl.acm.org/doi/pdf/10.1145/219260.219264
  31. https://webpages.tuni.fi/livelykernel/publications/TR6-JavaScriptConcatenation-Taivalsaari.pdf
  32. https://dl.acm.org/doi/10.1145/38765.38828
  33. https://link.springer.com/article/10.1007/BF01806111
  34. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy
  35. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze
  36. https://cfallin.org/blog/2024/08/27/aot-js/
  37. https://dl.acm.org/doi/10.1145/1094855.1094916
  38. https://dl.acm.org/doi/10.5555/564092.564099
  39. https://lisaac.org/
  40. https://iolanguage.org/
  41. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes
  42. https://w3techs.com/technologies/details/cp-javascript
  43. https://www.lua.org/pil/16.html
  44. https://www.lua.org/pil/13.html
  45. https://airsdk.dev/reference/actionscript/3.0/Object.html
  46. https://www.infoq.com/articles/ruby-open-classes-monkeypatching/
  47. https://glinteco.com/en/post/nodejs-vs-deno-vs-bun-in-2025-choosing-the-right-javascript-runtime/
  48. https://dl.acm.org/doi/pdf/10.1145/960112.28718
  49. https://code.visualstudio.com/docs/nodejs/nodejs-debugging
  50. https://github.com/features/copilot
Add your contribution
Related Hubs
User Avatar
No comments yet.