Monday, 1 September 2014

CFScript 2.0?

You will be used to me bleating about how Adobe have messed up a chunk of their CFScript implementation in ColdFusion 11 (and ColdFusion 9 for that matter too), eg: last week's "Example of the thoughtlessness of a generic tag to CFScript solution", plus "ColdFusion 11: cfloop in CFScript very broken"; plus some suggested fixes: "How about this for savecontent?" and "Another suggested tweak to CFScript: thread". But one of my readers has mentioned in passing a good approach to solving it, and revisiting all the things that are wrong with CFScript.

GaryF mentioned this in a comment:
I believe a solution has to be creating a new, clean syntax which can be used within tags like this: <cfscript version="2"> </cfscript> Adobe would have to create a new interpreter but it just kicks in if version=2 is specified.
Yes. This strikes me as quite a nice idea. One could either specify the version in the tag, or have some compilation options somewhere which tell CF to which version to default. This way, there doesn't need to be any backwards compat considerations: one just picks which level to run on.

Also both vendors can get rid of their shitty generic CFScript solutions, plus fix other things that have crept in over the years (writeDump() instead of dump(); writeOutput() instead of just output() even); implement everything that looks like a function as as a function ("ColdFusion: some built-in functions aren't actually functions. It seems."), and - really - implement the scripting side of CFML the way it should always have been implemented: comprehensively, carefully, thoughtfully and thoroughly.

Another upside here is that they could implement an annotation at the start of a CFM file along the lines of @scriptversion = 2 or something, and have script-only CFM files too. That said, CFMs should be for views; most code should only be in CFCs I guess, but the CFC would need the same annotation too.

The could even extend this to the entire language: have a <cfprocessingdirective version="2"> or some other sort of annotation in a CFM file to flag which version of the tag compiler to use. This way we could get rid of most of the tags and only continue to maintain view-appropriate ones, and fix up some stuff that's never been great but we've been stuck with because of backwards-compat excuses.

Rakshith indicated that ColdFusion 2016 would be less cautious with backwards compatibility issues... this might be the way to go with this.