Friday 29 August 2014

Example of the thoughtlessness of a generic tag to CFScript solution

I've repeatedly said that Railo and ColdFusion's way of implementing 100% CFML functionality coverage in CFScript was lazy, leaden, and detrimental to the language. Here's an egregious example.

<cfdbinfo> works like this:

<cfdbinfo type="tables" name="info">
<cfdump var="#info#">

So it's basically a function already (in functionality, if not in syntax): it takes inputs and returns an output. But that is a reasonable implementation for a tag.

What's the CFScript handling of it? It's a function, called cfdbinfo(). But is it? It looks like a function, but if it was a function we'd expect this to work:

info = cfdbinfo(type="tables");

That would be predictable and sensible (other than the unnecessary "cf" prefix). However that just gives us:

Variable CFDBINFO is undefined.

The error occurred inC:/apps/adobe/ColdFusion/11/express/cfusion/wwwroot/scribble/shared/scratch/blogExamples/cfml/cfscript/test.cfm: line 3
1 : <cfscript>
2 : //cfdbinfo(type="tables", name="info");
3 : info = cfdbinfo(type="tables");

Huh? Well not really "huh" because I know what the story is. It's not actually a function. It's just a weirdo function-looking thing. What the syntax actually is is:

cfdbinfo(type="tables", name="info");


So instead of engaging their brains and realising that <cfdbinfo> was a dead sitter to be a function (as it always was: it should never have been implemented as a tag), they didn't bother doing that. No. They concocted some weirdo new syntax, adding a whole new construct to the language instead.

And I dunno if any other language has odd "looks like a function, ought to be a function, but actually isn't a function", so this is yet another way in which Adobe is killing CFML... by increasing its incoherence and quirkiness and making it even less of an appealing prospect to people who don't already use it.

Railo is no better. They have also left this to the generic syntax... but at least their generic syntax isn't so leaden or confusing, as it makes no pretence of looking like a function:

dbinfo type="tables" name="info";

How easy it would have been for both vendors to put some effort into it, and to it properly.


If you see this CFScript approach as a poor implementation, hurts CFML's viability as a language from the broader-industry's perspective and needs redoing... consider voting for this: "Bin the generic CFScript approach and start again". It's been closed as "never fix", but that's not to say we can't let Adobe know we think they've messed up here and need to rethink some stuff.