Basics Before Beginning

Purpose This page explains in brief detail some things that you need to understand before ploughing into Superx++. Many of these concepts are general to many other languages and so you may skip them if you have encountered them before.
A class is a type that can contain functions in addition to variables. A class is far more than a complex record. It is a record that can behave in certain ways. In other words, a class possesses behaviour in addition to properties. Classes are a central idea to many object-oriented languages such as C++ and Java. They are also central to Superx++. Classes in Superx++ are implemented using the <class> statement. What classes do that make them very useful is provide a logical way in which to categorize entities in the real world. In such a sense, it becomes logical, for example when bulding a human resources system, to design a Company class and an Employee class, both of which shall possess special properties and behaviour to support the work flow of the human resources department's work. An important point to mention at this stage is that a class is a type or definition. It is not in itself an actual entity-- it is the definition of entities which can be created based on the definition (or class in our case). These entities are called objects. These objects are said to be instances of the class because they represent particular instances of the manifestation of the class.
Escape Sequences
Superx++ uses the XML and C standard escape sequences. The XML escape sequences for the < and > characters must be used to avoid the problems that XML parsers will have parsing the Superx++. Here is the list:
&amp; is the & character
&lt; is the < character
&gt; is the > character
&quot; is the double quote
\a is the bell alert
\b is the backspace
\f is the form feed
\v is the vertical tab
\' is the single quote
\" is the double quote
\\ is the back slash
\? is the question mark
\r is the carriage return
\n is the new line
\t is the tab
Run-Time Class Memory
Superx++ keeps track of the current definitions of all defined classes in a run-time store that is dynamically updated upon the definition, redefinition and deletion of a class. This run-time store is called the run-time class memory. Due to the tight-coupling between Superx++ and XML, it should come as no surprise that the run-time class memory is structured as an XML document. Empty class memory looks like this:

Defined classes are appended as child nodes to the <Classes> node. The fact that the class memory is an XML document precludes the need to perform an extra operation to serialize memory or classes in memory. This is a given fact due to the internal nature of the memory.

Inheritance is the phenomenon where a class or an object derives some properties and/or behaviour from another class. Single inheritance occurs where there is only one class being derived from. Multiple inheritance occurs where there are more than one class being derived from. The class being derived from is called the parent class or the super class. The class or object doing the deriving is called the child class or object.
When an object is created, it represents a particular instance of the manifestation of the class(es) it belongs to. In such a sense, the object is referred to in object-oriented terminology as an instance of the class. Therefore the process of creating an object is called instantiation. The process is a multiple-part process in general (and in Superx++). The following are the steps:
1) A call is made to instantiate an object
2) The object's structure is built (the object itself, its variables as well as other objects it contains)
3) A particular constructor method is called by the system automatically

After step 3) the process is complete and the object exists and has also been initialized. The initialization takes place in the constructor method. By default constructors do nothing. It is up to the programmer to place initialization and resource allocation code within the specific implementation of the constructor method required and the system will invoke it upon the appropriate circumstances. Instantiation in Superx++ is performed using the <node> statement. Constructor methods are implemented via the constructor member.

Run-Time Memory
Superx++ keeps track of the current definitions of all instantiated objects in a run-time store that is dynamically updated upon the instantiation, modification and deletion of an object. This run-time store is called the run-time memory. Due to the tight-coupling between Superx++ and XML, it should come as no surprise that the run-time memory is structured as an XML document. Empty memory looks like this:

Instantiated objects are appended as child nodes to the <xppRAM> node. The fact that the run-time memory is an XML document precludes the need to perform an extra operation to serialize memory or objects in memory. This is a given fact due to the internal nature of the memory.

A node in a tree-based hierarchical system is a particular entity which exists in relationship to other related entities. These entities are related via hierarchical relationships (parent, child or sibling). Superx++ is a tree-based language just like XML. Superx++ is tightly-based around XML and they share many similarities. They both have one root for every tree of nodes. Each node can also contain other nodes, as well as attributes and a value. Nodes are very good at portraying hierarchical data relationships. Superx++ is not only an object-oriented language based on classes but it is also a node-oriented language based on the XML tree structure. What Superx++ does is to specify that every object is a node in a tree. Remember, though, it is possible for a tree to contain a single root node with no descendants. The reason why Superx++ uses this object/node structure is that it becomes completely trivial and automatic to implement XML serialization of objects and the accompanying ubiquity that follows from this logic. The simple statement that implements XML serialization of objects (and indeed of whole programs as well) is the save statement. The simple logic for this is that since nodes and objects are synonymous in Superx++, and Superx++ is XML-based, then programs are automatically written in XML! The serialization of objects is helped in memory internally because the run-time memory space (some call this a "sand box") of a program is actually an XML tree (called an XML document)! So there really is no conversion from one representation of a program or objects from XML to something else-- the reality is that Superx++ is XML through and through!
An object is an entity of a defined type or class in an object-oriented system. Superx++ is an object-oriented language as well as a node-oriented language and has objects as well as nodes. The important nuance is that in Superx++ every object is a node and every node is an object. Objects are also called instances because they represent instances of the manifestation of the class(es) they belong to. The process of object creation is therefore called instantiation. An object contains members and methods which implement properties and behaviour respectively. These members take the form of variables and arrays whereas the methods are functions. The term member is loosely used in Superx++ to refer to both member variables and arrays as well as methods. This is because of the semantical fact that these are all members (or constituents) of an object. However, we qualify the two kinds of members by referring to the variables and arrays as member variables and member arrays.
Self Modifying Programs
Superx++ is an interpreted language with powerful object access of a program's own structure (because the language is based on XML). Because of this fact you can modify the program object (xpp) within the program. Doing this will alter the program itself. This can lead to very interesting results and is very easy to do. Because it is sometimes dangerous to modify a program on the fly, Superx++ also has the ability to save a program's state. You should save the state of a program before you modify the program.
State File
Superx++ contains a special statement that is used to save the current state of a file. This statement, <saveprogstate> saves important items about the program's current definition and memories to a special file called a state file. A state file can later be executed which has the effect of resuming the execution of the program whose state was saved. This is an useful feature in resuming execution of interesting parts of a program's execution, rather than restarting the program's execution from the beginning every time. The structure of a state file is an XML document:
      <xout>Hello World!</xout>
      <xout>\r\nAdios World!</xout>
   <MyParms var_double_pi="3.141921">
   <date>#24-May-2002 12:30:43#</date>

The sample state file above shows the various parts of a program.
1) The first child node is the <xpp> node which is the root node of the Superx++ program. In fact, the entire code of the program (as currently defined in memory) will be listed here. The reason for this is that the program may have been dynamically modified producing a difference between the program in memory and the program in source code/. The state file contains, as its first child, the program in memory.
2) The second child is the <currentlineindex> which specifies the particular node which was executed to produce this state file. This node will be a <saveprogstate> statement because that is the only means of creating a state file. The <currentlineindex> statement is especially useful when you have more than one <saveprogstate> statement in your program-- it enables the system (and you) to know which statement to resume execution from. Execution is resumed from the node whose index is <currentlineindex> + 1.
3) The third child is the run-time memory.
4) The fourth child is the run-time class memory.
5) The fifth child is the input stream XML document that was passed into the program.
6) The sixth child is the current date and time when the state file was created.

XML (eXtensible Markup Language) is a markup language that defines data into hierarchical relationships. XML defines the data into nodes within a tree structure with a single root node. The nodes are called elements whereas the tree is called a document. The elements can contain values, other elements and attributes. Details of XML can be found in the XML version 1.0 specification published on the W3C web site. A brief introduction to XML syntax:
Elements (or nodes) are written using open tags and close tags.
<MyElement> is the open tag that defines an element called MyElement.
</MyElement> is the close tag for the element called MyElement.
<MyElement id="123"> is the open tag that defines an element called MyElement which has an attribute called id with the value 123.
</MyElement id="123"> is the close tag for the element called MyElement which has an attribute called id with the value 123.

Elements also contain values or other elements as follows:



Both outer and nested elements can contain attributes. For a detailed description of XML please go to the XML specification at the W3C web site. Superx++ is based on the XML version 1.0 specification. Superx++ does not currently implement namespaces or schemas because it uses other more programmatic means to achieve typing of data. This also achieves some straghtforwardness in the presentation of a Superx++ programmer.

Superx++ and XML
1) Superx++ is based on the XML version 1.0 specification
2) Because Superx++ is XML compatible:
a) Superx++ can be transformed using XSLT etc.
b) Superx++ can be transported via HTTP and SOAP over the internet.
c) Superx++ can be parsed by any XML parser (of which there are many now)-- therefore a Superx++ program's structure can easily be analysed without requiring special IDEs (Integrated Development Environment).
d) Clients of services that produce XML data can use Superx++ services to produce the same datasets. This has the benefit of abstracting the data. XML now not only will yield data but can yield certain data based on certain conditions and other data based on other conditions. All of this happens without any change whatsoever to existing XML clients!
e) The Superx++ ISAPI filter enables Superx++ programs to be embedded in HTML and other text files. These programs will be processed before the results are passed back to the HTTP client.
f) Superx++ offers an easy way from within XML to programmatically access and modify XML data.
g) It is possible to construct a system where a program exists on one machine is sent via HTTP to another machine and is executed there as well.
h) Object and program serialization/deserialization are implicit.