Saturday, May 12, 2012

ColdFusion From an Outsider's Perspective

After changing my primary development language to PHP over a year ago, I've been able to get a new perspective on ColdFusion. One thing I've noticed is that people in the community spend less time focusing on new language enhancements and instead spend more time trying to make the language easier to work with. While this is a good thing, there are two pain-points that seem to come up over and over again that simply aren't issues in most other languages:
  • Case sensitivity
  • Struct key order
Would it really be so bad if ColdFusion was case sensitive? It would make converting ColdFusion objects to JSON or XML a lot more straightforward. "But Tony, I want to be able to define a function named getName but then be able to call it using gEtNaMe()". There should be no place for inconsistency in code. I honestly don't see any benefits to it not being case sensitive. Besides, with the addition of Hibernate, parts of the language are starting to become case sensitive already.

Would it really be so bad if structs maintained their correct key order? I see people building relatively complex solutions trying to solve this problem, often times having to dip into Java to accomplish the task. Wouldn't it be better if the native data type just worked the way you wanted it to? "But Tony, that's not how a HashMap works." Says who? Object keys stay ordered in JavaScript and associative array keys stay ordered in PHP. ColdFusion should work the same way.

In my opinion, making these changes adds a lot more value to the language than some of the other recent enhancements, such as WebSockets or REST.


  1. What I'd love to see is ColdFusion abandoning searching through scopes for variable names. Everyone acts as if always specifying the scope of a variable is a good idea, but really?

    VARIABLES.xintercept[1] = (-VARIABLES.b + sqrt(VARIABLES.b^2 - 4 * VARIABLES.a * VARIABLES.c)) / (2*VARIABLES.a)

    This is clear, is it?

    If I want to talk about the contents of FORM or URL or SESSION, I'll go ahead and specify scope. If I want to get something done with the current scope, don't go search for it -- find it in the current scope or throw an error.

  2. Anyone that does Javascript and ColdFusion should be able to handle case sensitivity in ColdFusion.

  3. I'm not saying people can't handle it, but why should it even be an issue?

  4. Case sensitivity has never been an issue for me in the 15 years I've been coding in CF. In fact I've never thought of it until I read this blog! I use camel case in all languages - it's easy to read, avoid confusion and provides consistency. getName() would always be typed as getName() in my JavaScript, CFML or PHP code.

    Structs changing their order - yes, I'm totally with you there. That has been a pain once or twice and required workarounds. I can't believe I've never put that on the wish list.

    Gary F.

  5. Case sensitivity becomes more of an issue when you start serialize structs to JSON. If I create a struct with user.firstName and serialize it, I would expect the JSON to contain a key of firstName, not FIRSTNAME.

  6. Ah, but it can Tony. It all depends on how you define your struct though:

    var retVal = {"success" = true, "message" = "", "data" = []};

    By quoting the keys, ColdFusion retains the case of the key. I'm also happy that CF 10 allows us to do struct notation more like JS:

    var retVal = {"success":true,"message":""};

    I'll agree about the casing, but understand why they haven't changed this (because it would break legacy code built on the last 9 versions of ColdFusion). The only place I cannot work around this is in queries.

  7. I'd much prefer that Javascript and Java were made case insensitive. It's silly to throw a error for missexecuting a shift key, needlessly costing me time and iteration. Computers should mitigate user error instead of punishing it. Though in that spirit IDEs themselves should spell check style correct your typing anyway. But there are no good CF IDEs anyway so... digress.


Note: Only a member of this blog may post a comment.