Posted in ColdFusion | Posted on 04-03-2008 | 2,256 views
One of my favorite features in ColdFusion 8 is the ability to create and populate structs and arrays in one line of code:
1<cfset a = ["paris","britney","lindsey"]>
2<cfset s = {name="Raymond",age="Almost 35",weight="204"}>
2<cfset s = {name="Raymond",age="Almost 35",weight="204"}>
This is so darn useful I can't imagine life without it.
ColdFusion 8.0.1 makes this even better by letting you nest these implicit creations:
1<cfset s = {name="Raymond",age="Almost 35",weight="204",kids=["Jacob","Lynn","Noah"]}>
2<cfdump var="#s#">
2<cfdump var="#s#">
Which results in:
Now obviously you don't want to go crazy with this. You still want to keep things readable!
(Sorry for all the blog entries. I can't sleep and I figured I'd share some of my favorite parts of 8.0.1.)
I agree with Tom that variables in function should probably be automatically scoped local, but at this stage it is probably a backwards compatibility issue. If you change it someone's code somewhere *will* break (because they did in fact mean variables scope and didn't prefix their reference).
Still it is hard to imagine a single issue that has caused more frustrating hours spent debugging than that one.
It's so lame to use backwards compatibility as an excuse for not fixing a problem. All they would have to do is allow you to override it in the administrator or the application.cfc like they have done with the allowExtraAttributes settings (see page 4 of the release notes).
Personally I would love to have the ability to override any of the administrative settings at the application level. And before some moron saids it: NO, using the adminapi is not the same.
Personally I think Adobe should break backward compatibility on a few (hell, a lot of) things. How many tags are poorly named, or have inconsistently or downright confusingly named attributes?
But you need to see it from Adobe's perspective. With every release they need to convince their existing user base to fork out for an upgrade. I'm sure CF8 shipped more than a couple units just because of the performance upgrade - because nothing beyond the install had to be done. The purchase price of CF is nothing compared with the potential manpower spent updating, testing and releasing fixes in conjunction with a CF version roll-out.
So I sympathise with Adobe's position. What they really need to do is ensure they have a roadmap so they can start deprecating features in one version and removing them in the next.
Putting additional options into CFAdmin to allow prior behaviours is not a general strategy that can be pursued everywhere, because then Adobe is still supporting an outmoded practice and (I imagine) obfuscating some of their code in the process.
" With every release they need to convince their existing user base to fork out for an upgrade"
I would have thought most people were on maintaince.
" potential manpower spent updating, testing and releasing fixes "
If it was an admin option, they could just flip the switch and get the old broken behaviour.
" additional options into CFAdmin to allow prior behaviours is not a general strategy that can be pursued "
Why not ? If the default is to allow newer, more correct code, but you can get the broken behaviour back if you need it, why would this lead to unreadable code ?
I'm off to read the rest of the changes.
@Tom's second comment, a switch in the Admin or per application would be great. It's shame that backward compatability stops things from being made better.
If adding switches to each new functionality in 3 next versions we will end up with dozens of then - thats not the way to go.
And I'm not a big fun of "making things by default". Yes - I would love to see 'var' keyword and be able to place it wherever I need inside cffunction.
The reasons why I don't see CFADMIN switches as a feasible way to address every possible backward compatibility issue is
1) Each new switch is a new dependency between the implementation code and the admin settings.
2) Each new switch is a dirty conditional in the implementation, which could mean a lot of extra testing and/or bugs not found prior to release
3) From a simple maintenance point of view, Adobe ends up supporting more code
4) ...For how long? Forever? Right through to CF15?
I agree that in this particular case (auto-VAR'ing) the pain of migration would be eased by a switch in CFADMIN. ... but that brings its own problems:
1. For users who are not aware of the setting, or what it means, the wrong setting would manifest itself in some pretty strange behaviours that could take a while to resolve.
2. All CF community projects (frameworks, etc) would probaby need to be written and tested in backward compatibility mode or simply not supported under the backward compatibility setting.
3. This issue would be impossible for code analyser to detect.
In my situation I would definitely like function variables to be automatically scoped function-local. I am mainly trying to say that the situation isn't as straightforward for Adobe as it might seem.
(Thinking about the Code Analyser, the new argumentCollection for tags must seriously reduce its effectiveness.)
That way backwards compatibility could be maintained for CFCs that need it, and new development could make use of the new behavior, within the same application.
It's not perfect (as the REALLY forward-looking would want this to be the default behavior), but it seems a reasonable compromise.
Another reason why not to autoscope vars: there are cases when I don't want to use var so any assignment will change the value outside function but in the same method I wish to have other var'd varaibles. How autoscope will deal with that? I see three overcomplicated solutions: tell all developers if they need variables outside cffunction but modifiable from cffunction they should explicitly use scopes (this, variables). Can't see this working.
The simpliest solution is declaring variables with var explicitly. I think it would be really nice to have debugger (or debugging output) telling me I'm using unvar'd variables.
In regards to the whole var scoping discussion, I completely agree that this should be the default. I'm sure some would not agree, but to me it would be worth the time to clean up legacy apps.
<cfscript>
var _init = {};
_init.testMe = {value="nudda3"};
return _init;
</cfscript>
... but this doesn't...
<cfscript>
var _init = {
testMe = {value="nudda4"};
};
return _init;
</cfscript>
<cfscript>
var _init = {
testMe = {value="nudda4"};
};
</cfscript>
Let me try it outside.
This is my server version of CF... what is yours? I should have it upgraded. (Unfortunately it doesn't say 8.0.1 ... )
8,0,0,176276
Works now also.
[Add Comment] [Subscribe to Comments]