This blog has been merged with my main blog. There will be no more posts on this blog.
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.
These are mechanisms in object oriented programming languages to identify the funciton/method to be invoked. The dispatch in the nomenclature is about dispatching messages to objects, as it is said in Smalltalk. It is equivalent of saying invoking methods of an object.
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.
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.
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:
Tags: single dispatch, double dispatch, multiple dispatch, multimethods
Michael Feathers illustrates nicely the problem of overcautious coding. The following should probably be coding principles:
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.
Roy Osherov has created Regulator - a regular expression generator. And it has a nice visual interface to specify the data and the parsing rules that creates the regular expression. If you want to know more about regular expressions head over here. Developers can use this to be more productive in creating regular expressions and use them in their own programming environment.
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
Subscribe
