An Architect's View

One of the new features in Adobe's ColdFusion 9 release that has excited a lot of developers is the broad range of enhancements to CFML's "other" language: CFSCRIPT. In the past, I've been very disparaging about CFSCRIPT and I've gone so far as to say in several public - and private - forums that I felt CFSCRIPT should be deprecated and no further effort spent on it. It was always a bit half-baked with weird restrictions and lots of important features missing. It was annoying to use, because you often had to switch back to CFML's tags to get things done. With increased use of CFCs, the restrictions in CFSCRIPT made it even more painful to use because you could not specify function arguments easily in CFSCRIPT - no types, no defaults - and you couldn't express a function's access or return type.When ColdFusion 8 appeared, with so many small improvements in CFSCRIPT, making it a bit more like JavaScript, those restrictions on function declarations were even more frustrating because other parts of CFSCRIPT had finally become almost pleasant to use. I was working with CF8 a lot and found myself using CFSCRIPT more and more because of the more JavaScript-like operators. Consequently, I found myself writing this sort of code a lot: Ugh! If you're a ColdBox user, you'll be familiar with this because it's Luis's style for writing event handlers. I don't know about you but the more I worked with CFSCRIPT, the more this style of function declaration started to annoy me! So, I started to simply use CFSCRIPT for public functions (and sometimes private ones) and just accepting a return type of "any" (the default) and arguments with "any" type (again, the default). Sometimes I even went as far as using arrayLen(arguments) to figure out whether optional arguments were passed in. Sad, but true. Enter Railo which allowed argument types and defaults in CFSCRIPT (I don't know quite when Railo added support for that but it was quite a long time ago). I still couldn't specify function return types and access but I could at least specify optional arguments properly: Fast forward to 2009 and the CFML Advisory Committee were hard at work trying to produce a specification of CFML and CFSCRIPT. Our intent was to create a specification that was just ahead of current practice to set the stage for vendors to implement over the next year or so. Adobe brought a number of CFSCRIPT enhancements to the table as a proposal - based on what they were considering for CF9 - and we adopted many of them, sometimes with a few changes. After a lot of discussion, the committee agreed on exactly what would be considered "CFSCRIPT 2009" but it didn't always match Adobe's implementation for CF9 and they were too far along in their cycle to change CF9 to match the committee's specification. We're still discussing exactly what to do about that. As an example of CFML2009 that doesn't match CF9, here's the CFSCRIPT version of the <cflock>: Here's Adobe's implementation: Back to our function declarations, CFML2009 specifies that you can provide the function access and the return type so, going back to our example, we can say: And indeed, CF9 lets you write this. Railo, which has allowed the argument form for a long time, also supports this function declaration as of version 3.1.2.006, currently available via the development update provider (http://dev.getrailo.org if you need to enter it manually, depending on which release of Railo you're running). I you're working with ColdBox (as I currently am), you no longer have to write those nasty mixed CFML tag / CFSCRIPT event handlers! Yay! CFML2009 includes many enhancements to CFSCRIPT. CF9 implements most - but not all - of them, as well as adding some that the committee felt were not "core language". Railo has started implemented the CFML2009 enhancements that we believe will make the most difference to developers and plan to implement all of CFML2009 over time (although it's not clear what to do yet about CFML2009 enhancements that are implemented differently in CF9).