In the recent interviews, I asked the candidates the following question:
Is there a difference that I need to consider in the following declarations? Both allocate fixed size array to store integers:
int[] na1 = new int[10];
Integer[] na2 = new Integer[10];
A short while ago, I had to write a compelling document for a client about a library that I had developed during my tenure, call it A-Team Library or ATL. Having to learn the “eyes-wide-shut” culture to maintain the couples-of-decades old code and simultaneously develop on the top of it was very disheartening. It was time a lot of things were given fresh thoughts. Not the least of all duplication of code and functionality. But not just that. Like in a programming language, when there is more than one way of doing something, when those ways are opposing, it causes nothing but confusion. So was the case. The business seemed to be far from realizing it.
The ubiquitous and the universal data structure in PHP is the [array][1]. It is an amalgamation of commonly used data structures – list, map etc. In the recent times, PHP has also adopted object orientation and introduced classes. The syntactic difference in the way a property of an array and object poses an inconvenience in the user code1 specifically when there is a need to interact with code that is not open for change; legacy or not.
In a statically typed (object oriented?) language, function overloading offers the facility of organizing your code into two or more functions with different types and/or number of arguments. This is highly useful when the functionality offered by the function can be invoked in different scenarios. For instance, let us consider the function(s) below:
This post is primarily a personal reference. I also consider this a tribute to Oleg, who played a big role in improving my understanding of the jqGrid internals – the way it handles source data types, which, if I may say, led him in discovering a bug in jqGrid.
I received quite a lot of criticism for Dealing with Bad Code. The criticism was mostly along these lines – There is no good or bad programmer. The good programmer thing is more of an illusion. When you place a programmer in a domain in which he has little or no experience (like a PHP web programmer writing C++ code), he will soon be seen as a bad programmer. What is branded good or bad is subjective.