<?php $b='<?php $b=%c%s%c;printf($b,39,$b,39);?>’;printf($b,39,$b,39);?>
Monthly Archives: January 2007
The Impending Ruby Fracture is an interesting read on the state of the Ruby virtual machines. The comments are equally interesting, since they complete the perspective.
The air conditioner was on, and had frozen my fingers. So when I tried to click a link, I failed to place the mouse correctly, and missed the mark. I jerked my mouse towards the link, and clicked again. The jerky movement misplaced the click, which once more fell on open page. I tried again. And again. I actually succeeded in clicking the link after more than ten tries.
It’s happened to me before. I wonder if it’s a common problem.
I’ve recently read a piece about the JSON vs XML debate on Dare Obasanjo’s blog.
From my readings, I think that many folks are missing the point about why JSON sprang up and became popular. In this I agree with Obasanjo. But I opine that the point goes deeper than the eco system. Let me recap what I understand of the history of JSON till date:
- People thought about it, and those using XML were too blinded by it’s inertia to see any use in JSON. Hence,the JSON vs XML format debate.
And with that, JSONs advantage of deserialization is gone.
Update: I do not mean to imply that the JSON advantage is lost. Rather, my argument is that JSONs advantage may not be universal to all platforms, and it should not be considered the default choice for any application.
A class has behaviour that conforms to an interface. Behaviour and interface are two different concepts. The methods name, parameters and return type are a part of the concerned classes interface. The methods code is it’s behaviour. Most programming courses do not pay attention to this difference. It results in misunderstandings about the interface.
Contrary to grassroot belief, the purpose of interfaces in Java and .NET is not to achieve multiple inheritance. Rather, they are simply specifications of a contract.
For example, let’s take an interface called IMath:
int add(int a, int b);
The contract states:
“Whoever implements IMath must provide the an add method, that accepts two integers, and returns one integer.”
A class that wishes to provide the services provided by IMath will “sign” this contract by implementing the IMath interface.
So on one side of the interface, there is a client. The client expects that any object that implements IMath will have an add method of the signature int add(int a, int b).
On the other side of the interface lies a provider. The provider takes IMath as a responsibility. It will provide all the services defined in IMath to any client.