Authenteo supports inheritance for versioning. Authenteo uses structural model inheritance in which the entire object graph of descendents of object are inherited and instances can modify proper descendents that are inherited without the orginial object graph being modified. In standard simple inheritance only first level properities of an instance, without modifying the inherited from object graph.

In order to accomplish this powerful inheritance, when a persistent object is returned from an access to a property of object A, and the property is inherited from object B, if C is a descendent of (pof discendent) of B, then version of instance of C is returned that is specific to abject A. This instance of C can be modified without modifying the original C, and the accesses to C that are accessed through A will have the appropriate modification. It is possible to determine of object C is a descendent of B by using the pjs.isDescendent function if it is not a descendent of B, the object A that inherits from B will not utilize an instance   version of C, but the original. This behavior holds true even if C is not a direct property of B, or A, but a property of one of its descendents. The instance of C that is specific to A can also be accessed by calling pjs.wrapper(A,C).



Java and JavaScript both have inheritance capabilities.  That is one entity will inherit values and/or behavior from another entity.  Authenteo also has inheritance, but Authenteo provides a more robust technique for inheritance.  Java and JavaScript use simple Single-Entity Inheritance which means that when an entity 1 inherits from entity 2 and entity 2 has a reference A to another entity 3, entity 1 will inherit the reference A to entity 3, but entity 3 will be treated the same whether referred to by entity 1 or entity 2.  However with Structural Model Inheritance, the entire data structure is inherited.  Therefore when accesses the A reference of entity it will not return the original entity 3 that entity 2 refers to, but a version of entity 3 which inherits from the original entity 3.  Therefore, if entity 3 has a field B, a modification can be made to the B field of A field of entity 1 without modifying the original entity 3 and hence possibly altering the nature of entity 2.

Language	Inheriter	Is a kind of/ Inherits from:	Inheritee	Depth of inheritance
Java	Sub Class	Inherits methods and fields from:	Super Class	Single Entity
JavaScript	Instance	Inherits functions, fields, and values from:	Prototype (accessed by .constructor.prototype)	Single Entity
Authenteo	Version	Inherits functions, fields, and values from:	Basis	Entire structural hierarchy

To better illustrate structural model inheritance versus single entity inheritance, lets consider an example of the definition of a car.  We may define a car to have properties like number of wheels = 4, and has headlights = true, we might define behaviors for the car like when the steering wheel is turned right, the car turns right, and so forth.  Some of these properties may merely be the default or normal properties that most cars, though there may be exceptions that are defined by specific cars.  We also might define properties about the engine in the car.  The engine may be considered an entity in itself.  Therefore we can define the engine in the car with properties like cylinders = 4, fuel=?gasoline?, and we might define the behavior, such as the power output as a function of the depression of the accelerator and the RPMs.

Now, let's define an entity that is a kind of car, like a sports car.  In Java we might have defined car as a class, and a sports car as subclass.  In JavaScript we might have defined a car as an object and the created another object corresponding to a sports car that used the car object as a prototype.  In Authenteo, a car would be the basis and the sports car would be a version of that basis.  Now, lets say we make a new definition in sports car for the steering, to make it more sensitive.  All the forms of inheritance can handle this fine.  And maybe we also define a better suspension system, and once again both forms of inheritance work fine, as long as we are dealing directly with the car entity. 

However, if we say that part of our definition of a sports car is that it a sports car?s engine has 6 cylinders, than we are dealing with the engine entity.  With single-entity inheritance, if we inherited the same engine object that the car object was referring to, then when we modify the engine object to have 6 cylinders, then we are also redefining the normal car?s engine since they are referring to the same object.  In order to deal with this problem, we need to make a new engine object for the sports car to keep the engine separate.  We may still want to inherit most of the other attributes about the engine like fuel=?gasoline?, and exhaust=?carbon dioxide?.  So we have to define the engine that belongs to the sports car to inherit from the engine that belongs to the car if we want to maintain these inheritances.  Now what if we want to define characteristics about the cylinder that is in the engine that is in the car? You can see how the issue inheritance of becomes complicated with data structures that a larger than just a single object.  Now, what if the car also including a list or array of parts.  These parts were not named properties of the car, they were just in a list that belonged to the car. If we want to make a modification to our definition of a sports car by changing the properties of one of the parts in a list, the issues is even more complicated.  We have to create a whole new list of parts, so that the list can include our new part that one property that has been changed.  Now if we change the list of parts in the car object, it will not be reflected in the sports car, because we redefined that list in the sports car, even though we really didn?t have a different list of parts, we just had to create a new list to facilitate our new part.

With structural basis inheritance, whenever a property of an object is access, the structural basis inheritance framework keeps track of which object every object belongs to.  Therefore this inheritance framework keeps track of the fact that the original engine object belongs the car object, and the sports car can inherit the car?s engine, but the framework will track the engine object that was retrieved from the sports car (that was inherited from the car) as the engine belonging the sports car without us having to redefine a new engine object.  If we make a change to engine belonging the sports car, than that version of the engine will be altered, without affecting the original car engine, and without us have to create a new object and define what object it inherits from.

This inheritance framework works by keeping track of all the childMods that a version has made of the child objects that belonged to the basis object where the version is inheriting from the basis (the version is ?a kind of? relationship).  The childMods can be made on any level of deep descendents of the initial basis object.  Therefore, this framework can also seamlessly deal with redefining a characteristic of a part on the sports car that was including in a list of parts inherited from the car.  This information is simply recorded in the definition of a sports car as an alteration of one of the descendant objects of a car.  The end user, can simply make modifications/definitions to the sports car, by modifying/redefining properties and behaviors at any level in the data structure that they see descending from the sports car without having to worry about whether or not it was inherited from another object and if the object will alter the object that this object is inherited from (such as the car and its descendants).  This greatly simplifies the user experience when working with sophisticated data models that involve inheritance.