Programming Structures and Syntax

## Introduction
In BindKraft, the goal is to use JavaScript to its fullest extend, by employing a clever OOP design based on the prototyping features of ECMA Script. 

Typically, an application, or extension programmer creates new types by inheriting from a set of base framework classes, in the single inheritance manner. In addition, we support an interface-like feature that allows classes to implement certain sets of methods defined by an interface, or use empty interfaces as class markers.

To understand the concept more easily one should view a Javascript program as both compiler and the program itself. While it is not physically true, the Javascript code actually constructs the class hierarchy, the analogues of virtual tables and the other features typical for compiled object oriented languages. This is all based on the prototyping Javascript feature.

### OOP features
What OOP features are supported/simulated?
* Single parent inheritance :
```javascript
MyClass.Inherit(ParentClass,"MyClass");
```
* Interface marking and interface implementation:
```javascript
MyClass.Implement(ISomeInterface); // implementation
```
<!-- example: MyClass.protocols = { PProtocol1: true, PProtocol2: true }; // marking -->
* Type information and type queries:
```javascript
v.is("MyClass"); // Checks if the class is or inherits a class or interface.
v.fullClassType(); // Returns the full class name as inheritance chain e.g. BaseObject::SomeClass::MyParentClass::MyClass.
v.supports("ISomeInterface"); // Checks if the class implements or is marked with a interface.
```
* Library wide supported notion for getters and setters:
`get_somename()` and `set_somename(value)` are treated in special manner by many library functions and are viewed as a property called **somename**.
* Class registry - all classes defined by the application are stored in `Function.classes` property:
```javascript 
var obj= new Function.classes["ClassName"]; // create class by its type name passed as string.
```
* Root object inherited by all classes with certain basic features that can be overridden (**BaseObject**).

The OOP layer, provides some useful features, like:
* Delegates and commands – classes that pack a this pointer and a function and are used as invokers of method over classes;
* Extended array functionality that allows search and manipulation of an array content using the object comparison features (equals method for example).
* A few geometry primitives (further extensions may be added);
* A service for message exchange between objects and between browser windows (opened using javascript in the same browser process).
Bubbling command from child to the root over the visual tree ("structural queries").

Unlike other object oriented designs, here there is no namespace support. A class name is uniquely defined from its inheritance chain. This full type name is not intended for functional purposes and is mostly means for debugging/tracing and sometimes comparison by type.

### The role of BindKraft classes
It is important to make a distinction between DOM types, native javascript types, and BindKraft classes. Types which are an extension of the BindKraft base classes are meant to serve either as controllers or extensions. They integrate with the DOM, support templates, data binding, event hander bindings, binding data formatters and so on. 

In some cases, when we create an abstract nongraphical structure, we only need to extend the functionality of some base framework class. For example, if we want to create an application, we would most likely extend the **AppBase** class, which implements some usefull application functionality. In other cases though, when our class needs to represent some object of the page document, it becomes necessary to associate the objects of our type with their respective DOM nodes, which are part of the actual document.

It is important to distinguish DOM nodes from objects of framework types. In the articles that follow, we will often mention the terms: *logical tree*, *logical hierarchy* or *logical object chain*. When we talk about such structures, we actually mean the tree, consisting of objects, with BindKraft derived types. These objects may have references to DOM nodes, but this is not mandatory in any way.

The next few sections cover the basic inheritance mechanisms, plus a brief description of some of the basic BindKraft classes.