Since JavaScript does not provide a way to syntactically denote a class definition, we'll use the with statement to mark the class definition boundaries. This will also make the example code smaller as the with statement is allowed to perform a series of statements on a specified object without qualifying the attributes.

function Calculator() {};
with (Calculator) {
    prototype._prop = 0;
    prototype.setProp = function(p) {_prop = p};
    prototype.getProp = function() {return _prop};
}

So far we have defined and initialized the public _prop variable as well as provided getter and setter methods for it.

Need to define a static variable? Just think of the static variable as being a variable owned by the class. Because classes in JavaScript are represented by function objects, we just need to add a new property to the function:

Calculator.iCount = 0;

Now that the iCount variable is a property of the Calculator object, it will be shared between all instances of the class calculator.

function Calculator() {
    Calculator.iCount++;
};

The above code will count all created instances of the class Calculator.

Encapsulation
Using "Calculator", as defined above, permits access to all the "class" data, increasing the risk of name collisions in inherited classes. We clearly need encapsulation to view objects as self-contained entities.

A standard language mechanism of data encapsulation is private variables. And a common JavaScript technique for emulating a private variable is to define a local variable in the constructor, so that this local variable is accessible exclusively via getter and setter - inner functions of the very same constructor. In the following example, the _prop variable is defined within the Calculator function and is not visible outside of the function scope. Two anonymous inner functions, assigned to setProp and getProp attributes, provide access to our "private" variable. Also, please note the use of this, quite similar to how it is used in Java:

function Calculator() {
    var _prop = 0;
    this.setProp = function (p){_prop = p};
    this.getProp = function() {return _prop};
};

What is often overlooked is the cost of such encapsulation in JavaScript. It can be tremendous, because inner function objects get repeatedly created for each instance of the "class".

Accordingly, since constructing objects based on the prototype is faster and consumes less memory, we cast our vote in favor of public variables wherever performance is critical. You can use naming conventions to avoid name collisions, for example, by prefixing public variables with the class name.

Inheritance
At first glance, JavaScript lacks support for the class hierarchy similar to what programmers of conventional object-oriented languages expect from the modern language. However, although JavaScript syntax does not support class inheritance as in Java, inheritance can still be implemented by copying an instance of a previously defined class into the prototype of the derived one.

Before we provide an illustration, we need to introduce a constructor property. JavaScript makes sure that every prototype contains constructor, which holds a reference to the constructor function. In other words, Calculator.prototype.constructor contains a reference to Calculator().

Now, the code below shows how to derive the class ArithmeticCalculator from the base class Calculator. "Line 1" results in borrowing all properties of the Calculator, while "Line 2" restores the value of the prototype, constructor back to ArithmeticCalculator:

function ArithmeticCalculator() { };
with (ArithmeticCalculator) {
    ArithmeticCalculator .prototype = new Calculator(); //Line 1
    prototype.constructor = ArithmeticCalculator; //Line 2
}

Even if the example above looks like a composition rather than inheritance, the JavaScript engine knows about the prototype chain. In particular, the instanceof operator will work correctly with both the base and derived classes. Assuming you create a new instance of a class ArithmeticCalculator:

var c = new ArithmeticCalculator;

expressions c instanceof Calculator and c instanceof ArithmeticCalculator will both evaluate to true.

Notice, that the constructor of the base class in the example above is called at the point when the ArithmeticCalculator prototype is initialized and not when an instance of the derived class is created. This could have unwanted side effects and you should consider creating a separate function for initialization purposes. As the constructor is not a member function, it can't be called through this reference directly. We will need to create a "Calculator" member function to be able to call super:

function Calculator(ops) { ...};
with (Calculator) {
    prototype.Calculator = Calculator;
}

Now we can write an inherited class that explicitly calls the constructor in the base class:

function ArithmeticCalculator(ops) {
    this.Calculator(ops);
};
with (ArithmeticCalculator) {
    ArithmeticCalculator .prototype = new Calculator;
    prototype.constructor = ArithmeticCalculator;

prototype.ArithmeticCalculator = ArithmeticCalculator;
}

Polymorphism
JavaScript is a non-typed language where everything is an object. Accordingly, if there are two classes A and B, both defining method foo(), JavaScript will allow polymorphic invocation of foo() across instances of A and B even if there is no hierarchical relation (albeit implementational) whatsoever. From that perspective, JavaScript provides a wider polymorphism then Java. The flexibility, as usual, comes at a price. In this case, it is a price of delegating the type checking job to application code. Specifically, if there is a need to check that a reference indeed points to a desired base class, it can be done with the instanceof operator.

On the other hand, JavaScript doesn't check parameters in the function calls, which prevents from defining polymorphic functions with the same name and different parameters (and let the compiler choose the right signature). Instead, JavaScript provides an argument object - Java 5 style - within a function scope that allows you to implement a different behavior depending on the parameter's type and quantity.

Example
Listing 5 implements a calculator that calculates expressions in a reverse Polish notation. It illustrates the main techniques described in the articles and also shows the usage of the unique JavaScript features, such as accessing object properties as an array element for a dynamic function call.

To make Listing 5 work we also need to provide a piece of code that instantiates the calculator objects and calls the evaluate method:

var e = new ArithmeticCalcuator([2,2,5,"add","mul"]);
alert(e.evaluate());

AJAX Component Authoring
All AJAX component authoring solutions known today can be logically divided into two groups. The first group specifically targets the seamless integration with the HTML-based UI definition. The second group drops HTML as a UI definition language in favor of certain XML. In this article we illustrate one approach from the first group, an analog to JSP tags, albeit in the browser. These browser-specific component authoring extensions are called element behaviors in the IE case or extensible bindings in the case of the latest versions of Firefox, Mozilla, and Netscape 8.

Custom Tag Dialects
Internet Explorer, starting with version 5.5, enables the JavaScript authoring of custom, client-side HTML elements. Unlike JSP tags, these objects are not preprocessed into HTML on the server side. Rather, they're legitimate extensions of a standard HTML object model and everything, including control construction, happens dynamically on the client. Similarly, Gecko-engine based browsers can dynamically decorate any existing HTML element with a reusable functionality.

It's possible, therefore, to build a library of rich UI components with methods, events, and attributes that will have HTML syntax. Such components can be freely mixed with standard HTML. Internally, these components will communicate with application servers, AJAX style. In other words, it's possible (and relatively simple) to build your own AJAX object model.

The IE flavor of this approach is called HTC or HTML components; the Gecko version is called XBL - eXtensible Bindings Language. For the purposes of this article, we'll focus on IE.

Enter the HTML Components - HTC
HTC or HTML components are also called behaviors. In turn they are divided into attached behaviors that decorate any existing HTML element with a set of properties, events, and methods, and element behaviors that look like an extended set of custom HTML tags to the hosting page. Together, element and attached behaviors provide a simple solution for authoring both components and applications. Here we'll illustrate the most comprehensive case, element behaviors.