Dec '99

Inheritance and Instantiation

Part 1

Nomenclature:

To be clear on the effects of inheritance and instantiation, there has to be definitions for these two concepts. Let us define the symbols "" and "" to be read as:

Just because the symbols defined above refer to "inheritance" and "instantiation", it does not mean that we are going to use those concepts in their usual sense. These symbols will be defined explicitly below. But we will also see that they match very well to our intuitive definitions of these two concepts. The language of this text also refers to the concepts of up and down. In the cases of "A B" and "A B" we say A is above B. Therefore we can speak of a path made from B "up to" A, or from A "down to" B.

Definitions:

An attribute of an object is either a method or a field. Every one of these attributes has to have a unique identifier, called a UID. Using this concept we define some functions that act on objects:

Here is an example to the application of the above definition. Consider a the set of all people (with UID="Person"). We also define all people to have a defined attribute (UID="Name"). If we consider a particular person (UID="Kyle"), then that person has an accessible attribute called "Name". More succinctly we say:

This paper is abstract and is not intended to provide implementation details. This example was used only to get a 'feel' for how the theorems below can be applied. In the example we see a notion of instantiation, we define it now formally, along with inheritance.

Definition A:

We will also add an axiom. It is important that for every attribute there is a definition for that attribute.

Axiom B (Reasonable Instantiation):

  

Part 2

Instantiation:

Definition C (Full Instantiation):

Theorem 2.1

Proof:

An object that is a direct instance of itself has strict consequences. You can see that any attributes defined in an object are also implemented. This will lead us to the definition of an auto object later.

Inheritance:

Theorem 2.2:

Proof:

"A A" can be used liberally in ER modeling if it happens to improve understanding.

Theorem 2.3:

Proof:

Theorem 2.4:

Proof:

This is the most important theorem of this paper. It allows for a closed, self-describing system. The implication of this theorem begs us to create a special definition.

Definition D (Auto Object):

Lemma:

Theorem 2.5:

Proof:

This is very interesting result. Due to the cyclical nature of the relationships, B is actually an instance of A. We will use this special construction to build the Object Hierarchy later in this paper.

Part 3

Interactions involving 3 objects allow us to see relationships between the instantiation and inheritance relations.

Theorem 3.1: (Transitivity of Inheritance)

Proof:

Theorem 3.2 (Transitivity of Instantiation):

Proof (3.2.A):

Proof (3.2.B):

What we can conclude from this theorem is that by inspection of the inheritance/instantiation hierarchy one can determine partial instantiation of any object, C, by finding a special path to reach an A. This special path must include one, and only one, instantiation relationship. The restriction of "only one" is demonstrated by the following theorem

Theorem 3.4

Proof:

Definition E (Remote Objects):

Theorem 3.5:

Proof:

 


  Part 4

Construction of a pure Object Oriented Hierarchy.

Theorem 3.4 gives us insight into the implications of a very special, but important scenario. We have rule system that, given almost any object, allows the construction of other objects that are not an instance of it. The impact of this conclusion is demonstrated by supposing that A is the description of ALL 'objects'. There could exist a C that is not an instance of A, and not an 'object' at all! Theorem 3.5 gives us the conditions that must be met to build an object that describes all objects. The emptiness of DEF(A) that allows A C, C.

Let us construct the top-most part of the object hierarchy:

 

We will make the Class of all Objects (aObject) and the Class of all Classes (aClass). Since the set of all classes is a subset of the set of all objects we can conclude that aObject aClass. Since aObject is also a Class, it is an instance of aClass (aClass aObject). Using theorem 2.3 we conclude that aClass is an Auto Object. Theorem 2.4 notes that aObject --*+ aClass; a necessary observation that aClass is still just an object.

Using this simple construction we could define attributes that would be common for all objects and all classes. But, as mentioned before, to successfully model everything, there are none. DEF(aObject) is empty, and DEF(aClass) is empty.

The hierarchy can be extended off these two objects. The aClass can be inherited to generate a Java "Class" object, along with all its attributes. The aObject can be extended to generate a Java "Object" object. The inheritance and Instantiation relationships can be added between the two, and all of the Java object hierarchy can be added.

The Java primitives are not objects in terms of the Java specification, but they are still objects in aObject sense. aClass and aObject objects can be extended to define the special attributes for these primitive objects. It is up to the implementor to determine if the JVM operations are attributes of the primitives, or stand-alone functions leaving the primitives with no attributes. Objects without attributes act as place holders, signifying existence, but lack of functionality or structure.

By adding something called Primitive Types, we can design a more traditional hierarchy. These primitive types add attributes from outside the DEF() and ATT() functions. These attributes are exposed in Primitive Attributes.