The Secret behind Bjarne and Herb's Papers on Unified Call Syntax !!!

A long time back, in one of my posts here, I had discussed about Extension Methods ... in C++; sorta! It seems that the grand daddy, Bjarne Stroustoup, had read my post, and was impressed. So he has published a paper - Call syntax: x.f(y) vs. f(x,y). Good thing except I don't like the idea of assuming x.f(y) for f(x, y) while the reverse is the actual idea of extension methods. You will know when you read his paper. It seems the commander, Herb Sutter, also was impressed with my post. Not only that he too doesn't seem to like the x.f(y) for f(x, y) idea. Great men think alike. LOL! So he published his paper - Unified Syntax. How is that?

Needless to say, I was completely kidding about the Herb and Bjarne about borrowing the idea of extension methods from my post. I wasn't even born when Bjarne invented C++. The papers are detailed and deep in considering various scenarios from a language standard perspective unlike my post where I just spotted the existing but unrealized possibility of the feature in C++.

While C++ produces awesome languages with superior and modern syntax, constructs and concepts, it takes a long time to do that for itself. That is a sad thing! Nevertheless, I am proud that I know and love C++.

A Simple Tree List View !!!

Digging up stash is one of the best pass times. You know you never know what you will find. I had an article written quite some time back but had not posted it anywhere. Not sure why. I posted it at CodeProject - A Simple Tree List View.

PHP Savers - PropertyBag !!!

The ubiquitous and the universal data structure in PHP is the array. 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.

JavaScript would allow you to access an object property either obj.propName or obj["propName"]. That does come in handy for sure. Besides, accessing the property by [] tags is the only way if the property name contains characters like hyphen: obj["prop-Name"]. At the user code level, it is fair to see an object as a bag of key-value pairs.

Along the same lines, it is not wrong to expect the same in PHP between an object and an array; although there is a fundamental difference2. The expectation arises when there is a lot of code that generates array (as output), and a lot of code that expects object (as input), or vice versa. Either code would primarily be interested in the getting or setting the properties/keys than the intrinsic. For that matter, the reasoning behind why an array or object was chosen by the author of either code is outside the scope of this post.

When the intent of the user code is to get/set the property or key, the syntax is just an inconvenience that gets in the way. Here is how one would access a property, or key precisely, of an array:

$arr["key"]    or    $arr[$key]

Here is how one would access a property of an object:

$obj->key    or    $obj->$key

To cope with the impedance mismatch between the code that generates an array and the code that expects an object (or vice versa), one is cast into another:

$obj = (object) $arr;    or    $arr = (array) $obj;

Of course, such casting has documented limitations. The restrictions would still apply to any solution trying to address the impedance mismatch problem.

In PHP, arrays are a bit funny to deal with. If one has programmed in other managed environments, it is evident that arrays are reference types. In PHP, arrays are value types; or sort of2. In other words, when you assign an array $a to $b, then $a is copied to $b. It makes perfect sense if one wants to make a copy of the array. If the array needs to be passed over several functions for read only or update purposes, it does not make sense to make copies over and over. We can reference the array:

$b =& $a;

An object in PHP - an instance of a class or stdClass, on the other hand, is a reference type (Thank God :)). Here the point is to avoid unnecessary copies of arrays and objects (created when casting from an array) that are created for merely accessing the properties.

That's where PropertyBag comes to the rescue. PropertyBag is an extremely useful class that can wrap over an object or an array (without creating a copy) or even create one from scratch, and make it possible to access the properties, or keys, either as an array or as an object, depending on the user code. Wherever one would return an array (or an object), an instance of PropertyBag could be returned without the need to change the code that consumes this return value. The caveat here is the consumer code does not make explicit type checks or something of the sort. You can grab your copy of PropertyBag from github:php-savers or read the excerpt of the class here below.

PropertyBag primarily helps to work with array or objects seamlessly, using either the array or the object syntax to access the properties. It also helps avoid creating copies of array when it is passed across functions2.

abstract class PropertyBag implements ArrayAccess {
    protected $_store = null;
    protected $_readOnly = false;
    protected function __construct(&$source, $readOnly = false);
    public static function fromArray(array &$source, $readOnly = false);
    public static function fromObject(&$source, $readOnly = false);
    public function isReadOnly();
    public function __get($name);
    public function __set($name, $value);
class ArrayBasedPropertyBag extends PropertyBag {
    public function __construct(array &$source = null, $readOnly = false);
    #region ArrayAccess Interface Implementation
class ObjectBasedPropertyBag extends PropertyBag {
    public function __construct(&$source = null, $readOnly = false);
    #region ArrayAccess Interface Implementation

  1. The code that I am working on is massive and consists of code several years old, a few years in the past and newly written. One can see the characteristics of the code change among the code from different periods. The newly written code, I believe is written with a great level of consciousness and awareness,  interacts with old code (give and take) passing in or taking arrays or objects. In no case, the old code could be changed to adapt what the new code is expecting or returning. Besides, the new code attempts its best to avoid copies of entities by leaning on object types whenever there is a chance instead of plain arrays. So there was an inherent need to build/work with something, an intelligent entity, that would bridge the gap among the code from different periods. The friction here was primarily the syntax difference in accessing the data rather than the intrinsic or nature of the data structure. Hence PropertyBag.
  2. Arrays in PHP are inherently value types but they disguise as reference types until a write is attempted. That means, array variables when passed across functions tend to avoid copies but the moment it is tampered (or written to), a copy of the array is made; copy-on-write. In most cases, a copy is not what is required. Instead the original array is intended to be updated. In cases where a copy is intended, making it explicit via clone mechanism is a good practice. PropertyBag will avoid copies of the array, and will also be able to hand out a copy when required through the toArray method.

Cool Regex Testers !!!

Anytime I have to play with regular expressions, I use one of the online regex testing web sites to come up with the regex I need. Last couple of times I had to come up with a regex for most common everyday stuff like dates and such. Oh yeah, last time it was date actually. I had a server response that had a date in the format yyyy-mm-dd, ISO format. I was working with JavaScript, and initially I was naive to use the Date class to parse the date in the response. Turned that there is difference in the way the date is interpreted by Firefox and other browsers.

Ok, this is not a rant post about the Date class but actually share some sites that help you with regular expressions, of course at different levels. Here is a list of such sites:

In the above list, I like the last but not the least - The cool thing about freeformatter is that it lists a lot of commonly used patterns such as emails, ip address etc. And I was lucky to find the ISO date pattern too, which saved me time. The uncool thing about it though, unlike other sites, is not haptic to the regex or input you type; instead requires an old-style submit button click to validate your expressions, and also does not show the matches (or capture groups).

Thought it will help anyone playing a lot with regular expressions!

PS: The actual issue with Date was not directly with the parsing but later on when the getDate, getDay, getMonth methods are used. While other browsers took the browser's time zone into account, Firefox did not. I was too bored to proceed with Date, and resorted to regex to parse out the date parts from my response. Here is the snippet of the code I used:

function formatDate(yyyymmdd) {
  var matches = yyyymmdd.match(/^(ISO DATE REGEX PATTERN)$/);

  if (matches == null) { return yyyymmdd; }

  var yyyy = matches[1];
  var mm = matches[2];
  var dd = matches[3];

  var date = new Date(yyyy, mm - 1, dd);

  return DAYS[date.getDay()].substring(0, 3)
   + ", "
   + MONTHS[date.getMonth()].substring(0, 3)
   + " " + date.getDate()
   + ", " + date.getFullYear();

Overloading vs Variable Arguments !!!

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:

// C# code
Dictionary<string, object> CreateResponse(string msg) {
 return CreateResponse(ex.Message, 0, false);

Dictionary<string, object> CreateResponse(string msg, int code) {
 return CreateResponse(ex.Message, code, false);

Dictionary<string, object> CreateResponse(string msg, bool success) {
 return CreateResponse(ex.Message, 0, success);

Dictionary<string, object> CreateResponse(Exception ex) {
 return CreateResponse(ex.Message, ex.HResult, false);

Dictionary<string, object> CreateResponse(string msg, int code, bool success) {
 var errorInfo = new Dictionary<string, object>();
 errorInfo['message'] = msg;
 errorInfo['code'] = code;
 errorInfo['success'] = success;
 return errorInfo;

Not a great example but I guess it is enough to explain my point.

The CreateResponse function has different overloads yielding itself to be used without much noise depending on the situation. If you have to create a response from within a catch block, you could go for the overload that takes an Exception object as input. And all the different overloads use or share a single core implementation, the one that takes all the possible inputs for CreateResponse. One would also have seen the same thing when implementing a class with multiple constructors. This is a very common pattern, and personally, a very useful one because you can be pretty sure about the inputs and their types. Of course, type guarantee is an integral part of any statically typed language.

Dynamic languages (such as JavaScript or PHP), on the contrary, do not offer any type guarantee, and hence could not possibly offer overloading, at least based on the types of arguments. They could, theoretically, offer overloading based on number of arguments. However, they don't, and for a good reason. Unlike statically typed languages, dynamic languages don't take the number of arguments for a function seriously. What that means is, in JavaScript or PHP, one could call a three arguments function without any arguments or less than or even more than three arguments. It is up to the implementation to deal with whatever arguments have been passed, including situations when one or more arguments have not been passed.

With the variable arguments, one could more or less simulate overloading but the implementation would be relatively messy or not natural unlike in statically typed languages. There would be a ceremony around argument checking - number and types of arguments, before they can be reliably used. It takes a quite an effort to make the function fail safe, execution wise. If the function expects an integer, it could not possibly work with a parameter that is an array. If this is all too much to worry about, one could just ignore implementing the guarantee, call it an assumption or ground rule, and and let the function fail; which is how code is typically written.

The other drawback around variable arguments, in the context of simulating overloading, is that it could end up not extensible; for instance to support future types and/or arguments. For instance, the type deduction at a particular argument index may not be possible any more if more arguments have been to be supported or even for the same number of arguments but with different types.

Actually my original musings was something else, besides compare/contrast overloading and variable arguments. It was about how the dynamic language runtime could, with my layman knowledge or as a consumer, handle type guarantee and so forth. I like to reserve a separate post, hopefully the next, to discuss about it.

Until then, I am going to let you try implementing CreateResponse in a dynamic language, say JavaScript, and enjoy the difficulty!

Getting reminded of the reminder !!!!

I have been using Android for quite some time now, and only recently I noticed that Android pops up a notification reminding you of a reminder. It says "Upcoming alarm - Buy Milk", where Buy Milk is the reminder I had set.

Is it smart enough to help a lazy volatile minded guy like me or is it trying to be my wife who would not rest until I buy milk? Don't know.

jqGrid: Handling array data !!!

This post is primarily a personal reference. I also consider this a tribute to Oleg, who was fundamental 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.

If you are working with local array data as the source for jqGrid, meaning you will get the data from the server but want the jqGrid not to talk to the server anymore, and want to have custom handling of the edit functionality/form and delete functionality, it is not going to be straightforward - you need to have a decent understanding of how jqGrid works, and you should be aware of the bug Oleg pointed in our discussion. I repeat this is all about using jqGrid to manage array data locally, no posting to server when you edit or delete, which is where the bug is.

    '#pager', {
        recreateForm: true,

        add: false,
        search: false,
        refresh: false,

        edit: true,
        edittext: 'Edit',
        editicon: 'ui-icon-tag',
        editurl: 'clientArray',

        del: true,
        deltext: 'Delete'
    }, { // edit options
        editCaption: 'Fix Error Record',
        url: 'clientArray',
        recreateForm: true,
        closeAfterEdit: true,
        reloadAfterSubmit: false,
        beforeShowForm: function (form) {
            $('#editmod' + gridId).addClass('grid-dialog');
            // You can disable or alter certain fields in the form if you need.
        processing: true, // very important or the custom handling will not work!

        // Edit - Custom handling of submit button in the edit form
        onclicksubmit: function (options, postdata) {
            var gridId = 'grid';

            var idInPostdata = + "_id";
            if (postdata[COL_MODEL_ROW_NO] == undefined & amp; & amp; postdata[idInPostdata] != undefined) {
                postdata[COL_MODEL_ROW_NO] = postdata[idInPostdata];

            var clone = jQuery.extend(true, {}, postdata);
            $(gridSelector).jqGrid('setRowData', postdata[COL_MODEL_ROW_NO], clone);

            for (var d_index = 0, d_length =; d_index & lt; d_length;
                ++d_index) {
                var p_data_row =[d_index];

                if (p_data_row[INDEX_ROW] == postdata[COL_MODEL_ROW_NO]) {
                    var dataObject =[d_index];
                    dataObject[INDEX_NAME] = postdata[COL_MODEL_NAME];
                    dataObject[INDEX_AGE] = postdata[COL_MODEL_AGE];
                    dataObject[INDEX_STATE] = postdata[COL_MODEL_STATE];

            if (options.closeAfterEdit) {
                $.jgrid.hideModal('#editmod' + gridId, {
                    gb: '#gbox_' + gridId,
                    jqm: options.jqModal,
                    onClose: options.onClose

            options.processing = true;
            return {};
    }, {}, // add options,
    { // delete options
        processing: true, // very important, else the custom handling will not work!

        // Custom handling of the delete functionality.
        // Prevents posting to the server but handles everything locally.
        onclickSubmit: function (options, id) {
            var grid = $('#grid');
            var gridData =;
            var selectedRows = this.p.multiselect ? this.p.selarrrow : [this.p.selrow];

            for (var index = 0, length = selectedRows.length; index & lt; length; ++index) {
                var rowId = selectedRows[index];

                for (var pd_index = 0, pd_length = gridData.length; pd_index & lt; pd_length;
                    ++pd_index) {
                    var gd_row = gridData[pd_index];
                    if (gd_row[INDEX_ROW_NO] == rowId) {
                        gridData.splice(pd_index, 1);

            // Refresh grid to previous page if the current page is the
            // last page in the grid; so that when all records of the
            // last page are deleted, we show the previous page.
            if ( === this.p.lastpage) {
                grid.jqGrid('setGridParam', {
                    page: - 1

            // Refresh the grid to load the changes

            $.jgrid.hideModal('#delmod' + gridId, {
                gb: '#gbox_' + gridId,
                jqm: options.jqModal,
                onClose: options.onClose

            options.processing = true;
            return {};
    }, {} // search options

Hope this post helps any poor soul battling the same or similar problem. You should definitely check out the question I had originally raised at, and the interesting discussion thereon.

Clean Code

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."

Although it sounds to make sense, I don't completely agree with that. Maybe the topic of the discussion was ambiguous. It wasn't the programmer but the code. I am not willing to spend my energy to demotivate somebody by branding him a bad programmer. But I will in reviewing anybody's code, not just brand it bad code but ultimately clean it up.

I believe programming isn't restricted to language. Although the language used to program has its impact on the way a problem is solved, it doesn't limit the programmer from losing the basics. In other words, a programmer should be able to program in any given language; of course he needs time to study the language. So if a PHP programmer is writing C++ code, he can't stick to his old habits and disregard memory management, and also be aware what is considered expensive in C++ unlike PHP. I agree that every language has its areas which cannot be mastered without exposure and time, for instance template meta-programming in C++. I doubt if one who has programmed in one of the dynamic languages all his time would even comprehend seeing results at compile time.

So if one transcends the language wars, programming is about three things - logic, semantic and structure. I am going to assume that those terms are self-explanatory in our context. And if I were to order them, they are reversed sound better. Although the order relates to the importance of each facet, one cannot and should not be sacrificed over the other. Each facet carries equal importance as the other and must be given attention to achieve good code. So the order is more of which one to attend to first.

Whenever I came across code that could made better, I had thought making a collection of such things. Well, I think I am up to it now. I am starting to write a series of posts (at irregular intervals), which will talk about how certain piece of code could be written so that it is easier for the reader to understand; in other words tell him why something is done a certain way. We see that line '...for the reader to understand...' everywhere in books and articles. The assumption there is that the reader is looking for the reason. If one were to just read code literally but never question why it is or is not written certain way, we got nothing to discuss. So every effort taken to write good code, and more importantly, maintain it that way, is not just for self-satisfaction.

Let me get started with the first one today, and it is about logic. Logic means how do solve a certain problem (specific and granular) efficiently. Efficiency does not mean only speed. If you can solve the problem in a comparatively fewer lines code without losing clarity and readability, then that is efficient. That sometimes involves educating ourselves and our peers with new techniques. For instance, in a language of your choice, how would you implement a function that returns the sum of all numbers starting 1 through N (including). One could start with this:

function sum(int n) {
    int total = 0;

    for (int i = 1; i <= n; ++i) {
        total += i;

    return total;

That's about 5 effective lines of code. It can be made succinct:
function sum(int n) {
    return (n * (n + 1)) / 2;

The above code is just one line. One could even question if we need a function. If programmers in the team were educated with the technique, calculating the sum doesn't need any encapsulation.

Some people will fight back saying what I am explaining here is just algorithms in action. True but it is not just limited to applying algorithms. What I am talking about applies even implementing an algorithm. I am talking about how can one write logic to improve the efficiency of code without losing the readability. I will leave it to the reader whether to agree with me or not.