[Reprint & Translation] Prototype Oriented

From http://www.brainyencyclopedia.com/encyclopedia/p/pr/prototype_oriented.html

Prototype-based programmingIs a style and subset of object-oriented programming in which classes are not present, and behaviour reuse (known as inheritance in class-based versions) is accomplished through a process of cloning existing objects which serve as prototypes. this model is also knownClass-less,Prototype-oriented, OrInstance-basedProgramming.

Prototype-based programming is a subsystem and a form of object-oriented programming. In prototype-based programming, classes are not real-time and behavior reuse (generally considered inherited from class-based languages) is achieved by copying existing prototype objects. This model is generally consideredClass-less,Prototype-oriented or interface-based programming.

The original (and most canonical) Example of a prototype-based language is the programming language self developed by David Ungar and Randall Smith. however, the Class-less programming style has recently grown increasingly popular, and has been adopted for the programming extends ages Cecil, Cr extends PT, newtonscr extends PT, Io, moo, REBOL, Kevo, and several others.

The original (and most classic) Example of a prototype-based language is the program language self, which was developed by David Ungar and Randall Smith. However, the Class-less programming method has become more and more popular recently and has been adopted by Cecil, javascr into PT, newtonscr into PT, Io, moo, REBOL, Kevo, and some other programming languages.

Contents 1 Comparison with class-based models 2 Object Construction 3 Delegation 4 concatenation 5 Criticism 6 ages 7 further reading 8 See also Contents 1. Comparison with class-based models 2 Object Construction 3. Authorization 4 Association 5 comments 6 languages 7. Further reading 8 See also

 

Instances

Comparison with class-based models

With class-based languages ages, objects come in two general types.ClassesDefine the basic layout and functionality of objects, andAre "usable" Objects Based on the patterns of a particle class. In this model,ClassesAct as collections of behaviour (methods) and structure which are the same for all instances, whereasInstancesCarry the objects 'data. The role distinction is thus primarily based on a distinction between structure and behaviour on the one hand, andStateOn the other.

In class-based programming, there are two types of objects in total. Class defines the basic layout and function features of an object, and the interface is a "usable" object, which is based on the style of a specific class. In this model, classes are represented as a set of behaviors and structures. The data of objects held by interfaces is the same for all interfaces. The differentiation rules are based on the structure and behavior first, and then the state.

Advocates of prototype-based programming often argue that class-based classes encourage a model of development which focus first on the taxonomy and relationships between classes. in contrast, prototype-based programming is seen as encouraging the programmer to focus on the amount of some set of examples and only later worry about classifying these objects into define objects which are later used in a fashion similar classes. as such, protocol prototype-based systems encourage the alteration of prototypes during runtime, whereas only a very few class-based object-oriented systems (such as the first dynamic object-oriented system, smalltalk) allow classes to be altered during the execution of a program.

Prototype-based programming writers often argue that class-based languages advocate the use of a model that focuses on the relationship between classes and classes. In contrast, prototype-based programming seems to encourage programmers to focus on a series of object behaviors ...... Because of this, many prototype-based systems advocate runtime prototype modification, and only a few class-based object-oriented systems (such as the first strong object-oriented system, Smalltalk) the class can be modified when the program is running.

Prototype-based programming is often associated with particle schools of thought in cognitive psychology which emphasize prototypes or exemplars as key attributes of the learning process.

Prototype-based programming is usually interspersed in the course of teaching cognitive psychology. He emphasizes prototypes and exemplars as keywords in learning.

While the vast majority of prototype-based systems are based around und interpreted and dynamically typed programming ages, it is important to point out that statically typed systems based around prototypes are technically feasible. the Omega programming language discussed inPrototype-based programming ^{[1] is an example of such a system.}

Because the vast majority of prototype-based systems are based on explanatory and strong type programming languages, it is important to note that static type language implementation is technically feasible based on prototype. The Omega language described in prototype-based programming is an example of this system.

Forth-like programming language, Kevo, do not propagate change from the prototype in this fashion, and instead follow a moreConcatenativeModel where changes in cloned objects do not automatically propagate guest SS descendants. [3]

Object Construction

In class-based versions 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 behaviour dictated by the chosen class.

In a class-based language, a new interface is constructed through the class constructor and optional parameters of the constructor. The result interface is modeled by the behavior and layout selected by the class.

In prototype-based systems there are two methods of constructing new objects, throughCloningOf an existing object, and throughEx nihilo("From scratch") object creation. While most systems support a variety of cloning,Ex nihiloObject creation is not as prominent.^[2]

There are two methods to construct an object in a prototype-Based System: copying an existing object or extending nihilo (null? Null ?) Object creation, because most systems provide different replication methodsNihilo objectThe method is little known.

Systems which supportEx nihiloObject creation allow new objects to be created from scratch without cloning from an existing prototype. Such systems provide a special syntax for specifying the properties and behaviours of new objects without referencing existing objects.

Provide ExtensionNihiloThe system that creates an object allows the object to be created from a blank space without copying it from an existing prototype. Such a system provides a special syntax to specify the behavior and attributes of a new object, without reference to an existing object.

CloningRefers to a process whereby a new object is constructed by copying the behaviour of an existing object (its prototype ). the new object then carries all the qualities of the original. from this point on the new object can be modified. in some systems the resulting child object maintains an explicit link (DelegationOrResemblance) To its prototype, and changes in the prototype cause corresponding changes to be apparent in its clone. Other system, such as

Replication refers to the process in which a new object constructs itself by copying an existing object (that is, its prototype. Therefore, the new object has all the attributes of the original object. From this point, the attributes of the new object can be modified. In some systems, a sub-object holds a direct link to its prototype (by authorization or similar means ). In addition, changes in the prototype will also lead to changes in its copies .. In other systems, such as forth-like programming languages, Kevo follows a more continuous model without spreading prototype changes, the Copied object will not be transmitted through its copy.

Dispatching to 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 behaviour-sharing behaviour between objects is thus the delegation pointer. unlike the relationship between class and instance in class-based object-oriented ages, 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 ammended over time without re-arranging the structure of its associated class 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 versions ages refer to both data and methods as "slots ".

Delegation

 

In prototype-based versions ages which useDelegationThe Language Runtime is capable

In a prototype-based language that uses delegation, the runtime language can locate the attribute or find the correct data by following the pointer of a sequence until the matching method is found. All these actions that establish behavior sharing require a delegate pointer. It is not like the relationship between classes and excuses in class-based object-oriented language. The relationship between prototype and its branches does not require that sub-objects have a phase.Because of this, sub-objects can continue to modify and... instead of organizing the structure as the class-based system. Another thing to mention is that methods can be modified, not just data.For this reason, most type-based languages extract data and methods as "slots"

Concatenation

Under pure prototyping -- which is also referred toConcatenativePrototypes and is exemplified in the Kevo Programming Language -- there are no visible pointers or links to the original prototype from which an object is cloned. the prototype object is copied exactly, but given a different name (or reference ). this process can be compared in some ways to biological mitosis. methods and attributes are simply duplicated as-is.

In pure prototype-also knownConcatenative prototypeFor example, the Kevo language does not contain pointers or links to the copied prototype object. The prototype object is indeed copied by renaming (or referencing) the object. This process is similar to biological split, where attributes and methods are copied as they are.

Advantages to this approach include the fact that object authors can alter the copy without worrying about side-effects privileges SS other children of the parent. A further advantage is that the computational cost of method lookup during dispatch is drastically CED when compared to delegation, where an exhaustive search must be made of the entire delegation chain before failure to find a method or slot can be admitted.

The benefits include that the object creator can modify the copy without worrying about the side effects of other child classes of the parent class. The advantage is that the consumption of the search attribute operation is much lower than that of authorization. The authorization search must traverse the entire delegate chain to determine whether it does not exist.

Disadvantages to the concatenative approach include the organizational difficulty of propagating changes through the system; if a change occurs in a prototype, it is not immediately or automatically available on its clones. however, Kevo does provide additional primitives for publishing changes internal SS sets of Objects Based on their similarity (so-calledFamily resemblances) Rather than through taxonomic origin, as is typical in the delegation model.

Concatenative has the disadvantages of spreading changes to the entire system; if a change acts on a prototype, it will not immediately or automatically take effect on all its copies. However, Kevo provides additional ways to spread changes in the object system. This approach is based on their similarity (the so-called family similarity), rather than originating from the taxonomy as representative as the delegated model.

Another disadvantage is that, in the most naive implementations of this model, additional memory is wasted (versus the Delegation Model) on each clone for the parts that have stayed the same between prototype and clone. however, it is possible to provide concatenative behaviour to the programming while sharing implementation and data behind-the-scenes; such an approach is indeed followed by Kevo.^[4]

Another disadvantage is that, in most of the natural implementations of this model, the extra memory on each replica is wasted (relative to the delegated model ), because the copy and prototype have the same part. Datatype). In particle, those concerns revolve around: correctness, safety, predictability and efficiency.

Criticism

Advocates of class-based object models who criticize prototype-based systems often have concerns that cocould be seen as similar to those concerns that proponents of static type systems for programming distributed ages have of dynamic type systems (see

In regard to the first three points, classes are often seen as analogous to types (and indeed, in most statically typed object-oriented versions ages they serve that role) and are proposed to provide contractual guarantees to their instances and users of their instances that they will behave in a given fashion.

On the last point, efficiency, the declaration of classes simplifies extends compiler optimizations that allow the development of efficient method and instance variable lookup. in the case of the self programming language, much development time has been spent on the development of compilation and interpretation techniques to improve the performance of prototype-based systems versus their class-based competitors.

Finally, perhaps the most common criticism leveled against prototype-based versions is that the community of software developers is not familiar with them, despite the popularity and market permeation of specified Cr limit PT. further, as prototype-based systems are relatively novel, and few and far between, best practices for software development using them have not become widespread.

Abcl/1, abcl/R, abcl/R2, abcl/C +

Ages

• Actor-Based Concurrent language, abcl:
• Agora
• Cecil
• Cel
• Ecmascr when Pt a.k. A. actionscr when Pt, dmdscr when Pt, then Cr then PT (first namedMocha, ThenLivescr platinum PT), Jscr platinum PT
• Factor
• Io
• Lua
• Moo
• Newtonscr platinum PT
• Obliq
• Openlaszlo
• REBOL
• Self
• Slate
• TADS

Computer Programming/Object Oriented Programming

Further reading

Has more about this subject:

• (1999) James Noble (ed.), Antero taivalsaari (ed.), Ivan Moore (ed .)Prototype-based programming: Concepts, ages and Applications, Springer-Verlag. ISBN 981-4021-25-3.

^Section 2.8 (pg.177). Günther blaschek, Omega: statically typed prototypes

^Section 1.2 (pg.17). chistophe Dony, Jacques malenfan, Daniel Bardou, Classifying prototype-based programming ages

^Section 1.1 (pg.14). Antero taivalsaari, Classes vs. Prototypes: some philosophical and historical observations

• Abadi, Martin, Luca cardelli.A theory of Objects, Springer-Verlag. ISBN 0-387-94775-2.

^Antero taivalsaari. Kevo, a prototype-based object-oriented programming lnaguage Based on concatenation and module operations. Technical Report lacir 92-02, University of Victoria, 1992.