Since there are not many posts on this blog, they will be reposted on the main blog acknowledging that they were already published there. Most of the posts here will be categorized under programming.

Single Dispatch

Typically, multiple methods or functions are given the same name, because the represent the same purpose. In the single dispatch mechanism, the method to be invoked in determined using the object, usually type of the object, on which it is invoked. It also includes the parameters, but the parameter types are identified at the compile time whereas dynamic binding or dynamic dispatch can be used for object on which method is invoked. This object is also syntatically highlighed, like

obj.behave(the, arguments)

Most of the conventional and popular languages, like C++, Java or Smallatalk inherently support single dispatch mechanism.

Double

Why is anything more than single dispatch is being considered? Because in the real world it is required. In the real world, the behavior between two objects is not dependent on both of them and not just one. Lets consider an example.

Your behavior would change when you face other humans, the domestic cat or the tiger. This means that your actions are dependent not only on you but also on whom you face. This cannot be incorporated using the single dispatch mechanism.

So we come up with double dispatch. It is in fact a simulation using the single dispatch mechanism, and hence is not completely extensible. Consider the following example code:

class Human;
class Cat;
	
class Animal
{
    public:
        virtual void face (Animal& animal);
        virtual void face (Human& human);
        virtual void face (Cat& cat);
}
	
class Human : public Animal
{
        virtual void face (Animal& animal)
        {
            animal.face(*this);
        }
	
        virtual void face (Human& human);
        {
            // shakehand
        }
	
        virtual void face (Cat& cat);
        {
            cat.face(*this);
        }
}
	
class Cat : public Animal
{
        virtual void face (Animal& animal)
        {
            animal.face(*this);
        }
	
        virtual void face (Human& human);
        {
            human.face(*this);
        }
	
        virtual void face (Cat& cat);
        {
            // run
        }
}

This code works. What is done here is that two calls are used to identify both the types involved. Consider this code:

        Animal& acat = Cat();
        Animal& ahuman = Human();
        ahuman.face(acat);

Here, when ahuman.face(acat) is invoked, it in turn invokes Cat::face(Human&) at which point both the types are determined. This is the double dispatch mechanism.

However, as you can see, the biggest disadvantage is that the base class Animal has to know all the derived classes. Everytime a new animal is added, the interface of Animal has to change making it impractical, exactly what the Dependency Inverstion Principle advises us to avoid.

Multiple Dispatch

So we need multi dispatch, also called multimethods. The multidispatch mechanism considers all parameters equally and hence can provide easier and more extensible implementations. Some of the languages that support multiple dispatch are Common Lisp, Dylan, Nice, Scheme and Slate.

One of the common designs of multiple dispatch is to separate the methods from the class (which contains the structure). This allows for treating all the parameters equally.

Some of the conventional languages also support multimethods through extensions - Multimethods for Python, Multimethods for Perl, MultiJava, Ruby, C++ with Multimethods.

More Reading:

• Double dispatch @ Wikipedia
• Multiple dispatch @ Wikipedia
• Multiple Dispatch - A new approach using templates and RTTI
• Beyond mainstream object oriented programming

Tags: single dispatch, double dispatch, multiple dispatch, multimethods

Spurious null checks are a symptom of bad code.

The reactive thing whenever there is a core dump or crash because of nulls or empty pointers is to add a check of null and wash your hands off it. The right thing would be to find out origin of the null and try to avoid it as much as possible. It is not only that the if can cause performance loss, it can inadvertently cover up the malicious code that generates the null.

It is also easier to program to an interface where the callee does not throw nulls so that the multiple callers don’t have to check for them.

Tags: null, conditional, coding.

The Regulator is an advanced, free regular expressions testing and learning tool written by Roy Osherove.
It allows you to build and verify a regular expression against any text input, file or web, and displays matching, splitting or replacement results within an easy to understand, hierarchical tree.

However in such applications the real challenge is to create a rich UI that will enable expressing all the possible formats of data and all the possible ways of specifying the parsing rules. More fiddling with it will tell us whether it is really upto the challenge, but a brief introduction has resulted in a pleasing experience.

You will also find a link to a more ambitious project - Regulazy.

Regulazy is an attempt to build a small “Expert System” for creating .NET Regular Expressions.
It lets the user create an expression based on a real life example of text they would like to parse.
As the user interacts with Regulazy using the mouse, Regulazy offers the user possible expressions that would fit the currently selected text. As the user selects “rules” to apply on various parts of the text,
a regular expression is built automatically in the lower application pane.

Regulazy goes a step further from Regulator to suggest the best matches for a real life data. Users can use sample text to specify the kind of data and see real time preview of the results. It is still in alpha stage.

Regular Expressions themselves are technology agnostic, I really wish that both these tools are not OS or platform specific. I will try and see if they work on other OSs by using Mono.

Tags: regular expressions, regulator, regulazy

So welcome to the Web 2.0 JavaDoc. The default way of looking up is searching. This is made easier with features like autocomplete.

Java API documentation are displayed in a style that is radically different from the classic javadoc style that ships with the JDK. The documentation includes class source code (where available), ability to leave user notes and ability to transparently navigate between APIs by following code references.

However, the drawback is that it does not have Sun’s JDK documentation, as mentioned in the FAQ.

I hope even gotAPI follows this.

Tags: javadoc, javaref, api, documentation