April 2002
Primitive Attributes
There are two problems that Primitive Attributes solve. The first is the fact that information is not action. A database containing a description of all the classes and functions would be interesting, but it would not do anything. Formal databases, by their nature, only store information. Never do they act on the data, those actions come from applications. The second problem is the clarity of the class hierarchy. As it stands, the rules introduced in Inheritance and Instantiation allow any combinations of inheritance and Instantiation. This can lead to classes with attributes that appear useless, or confusing. By adding the concept of Primitive Attributes we will impose intuitive order to the structure without limiting its expressibility.
Primitive Attributes are not accessible to the database. They are implied, and implemented by the DBOS. But like attributes they do follow the inheritance and instantiation rules.
Class Class Attribute:
Problem:
The world of objects and unrestricted instantiations (described in Instantiation and Inheritance) makes for a system that is complex to implement and comprehend. The Class Class attribute acts as a restriction on the instantiation of objects. Even though instantiation is restricted in use, it turns out that describing hierarchies is not. We can see this is true by acknowledging that nothing restricts us from having all objects inherit from the Class Class.
Prototype based languages (such as Self), remove the clarifying distinction between classes and objects. As a result, programs are more difficult to understand and resort to prototypes (read classes) to reestablish clarity.
Description:
The set of objects is partitioned into the set of classes, and the set of objects (not classes). Only classes are allowed to have instances, and those instances are objects. Classes with the Class Class attribute have instances that are classes.
Benefits:
The Class Class attribute acts as an indicator to the application programmer. It indicates what what objects are purely descriptive, and what objects may have instances in the future. This can help with making the application more efficient. It also keeps development clear; much ontological research has never merged the traditional concepts of class and object to maintain clarity.
Summary:
I believe few will dispute the clarity that classes bring to the design of an application.
Table Class Attribute:
Problem:
There is a common pattern in almost all programming languages, it is the concept of a set. Each one of these languages implement a set as a primitive structure. This structure manifests itself in the form of an array or a hash or other. We note the one useful property of the set is that it can be accessed in O(1) time. Without a primitive set, a set would have to be constructed explicitly by making a linked list or a tree. This type of implementation is, at best O(lg(n)). The choice of set depends on the language designer's desires. Sometimes it is for ease of implementation, like an array, or maybe ease of use, a hash. The DBOS has another desire in mind: parallelism. DBOS takes its primitive set structure from DB theory, the "relation" or "table".
Description:
The Table Class attribute derives its name from the fact that all the members in the set are of same type, called records. As mentioned already, the table is not ordered. The operations that can be performed on the tables are declared in the Table Class interface.
Benefits:
First, DBOS has a goal to support implicit Massively Parallel Programming (MPP). If there are structures in use that have order, then that order will be taken advantage of by the application programmer. This will result in extremely complex logic for unraveling the dependencies of the data. Second the uniform size of the record in the table allow for easy implementation with little or no detriment to expressibility. The higher level layers isolate the application programmer from ever experiencing the consequences of equi-typed records.
Summary:
A programmer must be aware of the distinction between a table as an object, and the set of records it represents. For example, listening to a table for a change in its attributes is different than listening to all the records it contains and any changes to their attributes. This duality exists in all primitive types, but is commonly confused when dealing with tables.
Function Type Attribute:
Problem:
To have the DBOS execute code, there must be a way to convert action descriptions into action. Action is represented by the function instance. Functions, function instances, and function types are a significant portion of the core DBOS. They have been delegated to a separate document: Functions.
Description:
Much like the Class Class Attribute, only distant instances of objects that have this attribute are affected. Any class that inherits the Function Type Attribute will inherit the ability to declare functions. Only instances of those function declarations are executable. There are more papers that provide a detailed description of implementation.
Benefits:
The Function Type is the minimum concept required to implement compilation, interpretation and partial evaluation. Of all the attributes mentioned here, this is the only one that is necessary to bridge the gap between description and operability.
Summary:
Function Instances are accessible by the database system as records. They also provide executability that allows the DBOS to be Turing complete.
Message Type Attribute
Problem:
DBOS uses a messaging passing paradigm. Messages usually last a short time. For this reason it benefits the DBOS to not put messages into a table. The Message Type Attribute acts as an indicator to the volatility of messages. More on messages is available in the function documentation.
Description:
A message object is a piece of memory that holds the parameters sent between caller and callee. Any distant instance of a class with the Message Type Attribute will not be available to for reflection by the DBOS.
Benefits:
This attribute exists because it solves some of the implementation problems. One problem is the addition of a message into the message table. If such an operation was allowed, then DBOS would broadcast a "AddRecordComplete" message. This new message would have to be placed on the message table. An infinite recursive loop is generated, and no real work gets done. There are other ways to solve this problem. This was the one chosen.
Summary:
Messages are volatile, but the underlying implementation need not concern the programmer, it will always appear as an actual message pass. In the future this attribute may be dropped. There is a need for messages that travel far, and subsequently a need for the tables that hold them.
Field Class Attribute
Problem:
Usually, when the record data is compressed, or tightly packed, it is necessary to read all the bits to find the values of a single element in the record. For example, suppose you are storing phone numbers (10 digits) and the sex of the person (Male, Female, Unknown). The total number of bits for the former is 34, the later 4, for a total of 38 bits. But the total number of possibilities, 30 billion, can be represented in 35 bits. The fields that represent these two values must have the procedure for extracting the attribute values out of this single 35 bits. The need to abstract the value of a field from the BitField of a record is done through The Field Class attribute.
Description:
Any class that inherits the Field Class Attribute also declares bit space in the record. As pointed above, the bit space need not be represented in an exclusive, contiguous, series of bits.
Benefits:
The use of the database paradigm at such a low level calls for a primitive that can extract attribute values from a record. Fields are not essential from a Turing Complete point of view, but they are essential for storing data efficiently. Fields are definitely useful for clarity of design.
Summary:
Fields are the only method for storing data efficiently. They are primitive constructions because of their usefulness to the application programmer.
April 2002: Updated