Wednesday 29 July 2015

ColdFusion: complete the implementation of associative array notation

This'll be a quick one (not least of all because I only have about 20min to write it).

CFML has the ability to reference struct (and by extension object) keys either statically via dot notation, or dynamically via associative array notation, eg:

someObj = {
    someKey = someValue

value = someObj.someKey;

whichKey = "someKey";
value = someObj[whichKey];

This is cool, but it doesn't work when referencing functions, eg this does not work:

someObj = {
    someFunction = function(){
        // do some stuff

result = someObj.someFunction(); // all good

whichFunction = "someFunction";
result = someObj[whichFunction](); // nuh-uh

This errors with:

Invalid CFML construct found on line 2 at column 13.

ColdFusion was looking at the following text:{

If associative array notation had been thoroughly implemented, this ought to work. However I suspect this latter situation did not occur to Adobe when doing the implementation.

(Aside: this all works fine on Lucee, so it did occur to them).

Fair enough that they overlooked it: it's a less common use-case than with general value-based keys. However not fair enough that the shortfall was pointed out to them back in ColdFusion 8, in 2007 (3033950), and they - to date - still haven't fixed it. And to be clear: this is a bug that this doesn't work. It's incomplete implementation.

The ticket was closed with our favourite "not enough time".

This came up again during the ColdFusion 10 pre-release (so a few years back now), and instead of just finishing the work they started, Adobe instead decided to create a new function to call functions via a dynamic name: invoke(). That was a lazy-arse, completely inelegant solution if every I saw one. How embarrassing for their language designers.

However they still need to complete the associative array notation, and given they're now in development for ColdFusion 2016, it's the best time for them to find the time to deal with it properly.

If you agree with this, can you please put your oar in on ticket 3033950, and encourage them to look at this again.

Adobe should be striving to make CFML a good language, not simply doing whatever is convenient for them when they're wondering if they have enough time to do their work properly.