There is no magic wand. As usual, a Transframe class describes a set of objects. It usually contains the following:
The object structure is the format used to hold a set of component objects. Object structure are described by a number of local variable declarations. Objects referred by these variables are member objects.
The object functionality is the capability of an object to spawn its component objects at run-time. This capability is described by a set local class declarations within the class body. These classes are member classes. Note that C++ member functions are a special case of memeber classes whose instances are activities within the object.
Let us consider an example:
class Cruiser
{
function turn_on ();
function turn_off ();
function increase_speed ();
function decrease_speed ();
private:
state: enum {on, off} = off;
ref_speed: cardinal;
};
state and ref_speed are variables that describe the structure of a Cruiser object, i.e., a Cruiser object has two component objects -- a state that indicates whether the cruiser in active in an automatic control of the vehicle speed; and a reference speed that indicates the vehicle speed under the control.
turn_on, turn_off, etc. describe the functionality of a Cruiser object. They are member classes whose superclass is function. We usually refer them to member functions.
To create an object of a member class, we must create it as a component of an enclosing object who is of the type of the enclosing class. Therefore, we should always provide an enclosing object to create a component object of a member class. For example, if we want to created a turn_on object, we must give the cruiser in which we should created this object. A turn_on object is an activity (a behavioral object) than performs an turn-on function. The activity (object) is deleted when it is finished. For example,
cruiser: Cruiser; cruiser.turn_on();
the first line creates a Cruiser object. The second line creates a turn_on activity (a component object) within the object cruiser. Since turn_on is sequential function, the program execution thread cannot go ahead until the activity is finished (deleted) after its creation.
I'll introduce more aspects of a Transframe class such as dynamic parameterization, subclassing rules, meta members, mutiple interfaces, constructors/destructors, type dependencies, etc. in my following columns.
A Transframe class is similar to a C++ class except it is a first-class object. Classes are objects that can be passed as values. Unlike other languages like Java and Sather where classes are only pseudo object which is implemented by class tags, a Transframe class is a real object that has states (the value of meta member objects) and can be defined by users. For example, given a class array, it has at leaset two states: ElementType and size. A class is a true object, which enables the environment to handle classes dynamically. If there is a magic wand, this is all the secrete of the magic. Freezing/melting is mainly an environment issue, the language provides a feasibility, rather than the mechanism itself.
A class can be in either the fluid state or the solid state.
When a class is in the fluid state, its object structure and object functionality can be modified. When it is frozen into the solid state, its object structure and object functionality are also frozen into a state that cannot be changed until it is melted into fluid again.
A melted class is loaded into runtime system. A dynamic class data structure is established for dynamic configuration, as shown below, a dynamic data representation of the class Cruiser.
Adding, deleting or modifying the existing member or member class declarations can be done dynamically through a visualized class diagram in the MagicFrame (environment) class design interface, and the data structure will be modified by the MagicFrame class manipulation system. We will examine a dynamic modification case later.
A frozen class has two different class codes -- simple class code and complete class info. Simple class code contains basic information about a class, which used for dynamic binding, and is similar to a C++ virtual function table in a more general sense. Complete class info contains the semantic information for a class which is used for melting a class into the dynamic programming environment.
Both codes are stored in the secondary storage. They are linked (statically) or loaded (dynamically) only when they are required. This is different from a C++ or Java implementation where object codes and class codes are bound permanently in excutables and the penalty is always there no matter you want it or not.
Melting is process to convert a class/object representation in the static environment to a dynamic class data structure as described above; so that the structure and functionality of the class/object can be modified without re-compilation.
Dynamic programming environment contains code interpreter for dynamic scripting, a graphical class/object manipulation interface for modifying the structure, functionality, and the dynamic class hierarchy.
When a class/object is melted, all the client class/object will also be melted. A client class/object is one of the following:
Suppose that we want to redesign the Cruiser system to include functions to increase/decrease the reference speed. And we are not sure that whether the cruiser system should be an autonomy that controls the speed by itself, or it should provide an interface for others (say, a monitor) to increase/decrease the speed. Instead trying it in time-expensive compile-test cycles, we melt the Cruiser into the dynamic programming environment.
When Cruiser is melted, the whole Driving System, which encloses the cruiser, is melted also. Using the MagicFrame graphic class manipulation interface, we added to new member classes to the Cruiser:
function increase_ref_speed(); function decrease_ref_speed();
and we deleted two old function: increase_speed and decrease_speed.
We reset the system, run, and get a run-time error, telling that a deleted member class, increase_speed, is called in a monitor's event handler. We forget to rewrite monitor's event handler.
We eventually find that it is not possible for a Cruiser to have a separated interrupt source because the hardware provides only one interrupt source. It is then impossible to let a cruiser be an autonomy. We then undelete the member classes increase_speed and decrease_speed in Cruiser.
We reset the system, run, and find that the cruiser reference speed does not response to the reference speed increase/decrease buttons. We should add two more cases in the monitor's event handler to deal with the signal from the two newly added buttons.
Freezing is process to convert a class/object representation (dynamic class data structure) in the dynamic environment to a static executable code as well as type informations and source code generation.
The structure and functionality of a frozen class/object is a snapshot of the structure and functionality currently represented in the dynamic class data structure. Freezing is an process of on-spot compilation. Instead of compiling source code, it compiles the dynamic class data structure and generate both the static executable and the new source code. This process may fail if there is any error detected. We can make correction in the dynamic programming environment and then try to freeze it again. The frozen code will be type-error free.
When a class/object is frozen, all the melted classes/object that have this class/object as a client will also be frozen. They one of the following:
Therefore, if we freeze the object Cruiser, the whole Driving System will be frozen. And a new executable is generated. The executable as efficient as the original one and can contain object code only, which is equivalent to the code written in C. A new source code will be generated also to reflect the modification.
Transframe has a type system that offers a transformable framework either freezable in dynamic programming system or meltable in static type system. Transframe enables the environment, MagicFrame, to support dynamic typing provided by a dynamic language. It also enables a software product to have the size and speed equivalent to a product developed by traditional static languages.
Within Transframe, classes (functions are unified into classes by Transframe) are first-class objects. They can be manipulated at run-time. New subclasses and new functions can be created at run-time with run-time values. With dynamic class management, classes created at run-time can be modified without rebuilding. Classes in a program are statically defined in the program context. They are predefined classes. They cannot be modified at run-time. They are frozen. The subclass relationships among all the classes in a program constitutes an acyclic graph. This graph is called a static class hierarchy, which cannot be changed or modified in a system generated from the program. We call this property static typing.
A system can extend a static class hierarchy by defining new subclasses at run-time. Classes created at run-time are dynamic classes. A dynamic class is created on the base of a number of static classes or other dynamic classes. The extended part of the class hierarchy is the dynamic class hierarchy. Both dynamic classes and the dynamic class hierarchy can be modified at run-time. We call this property dynamic typing.
A static class can be melted into a dynamic class when a change is required. When class A is melted, any static subclass of A will also be melted. The class information generated by the compiler will be loaded from a semantics database to construct an associated dynamic class structure. Any access to a melted class from the client (either a static or a dynamic class) will be typed checked at run-time.
A dynamic class can be frozen into static class by on-spot code generation, compilation, and dynamic linking and loading. When a dynamic class A is frozen, any dynamic superclass of A will be frozen also. The class information will be generated by the compiler and stored in a semantics database. Any static clients that have access to frozen classes will be recompiled and typed checked at compile-time to ensure correct usage. The fronzen code shall not generate any run-time type error or exception.