One of my favorite features in ColdFusion 8 is the ability to create and populate structs and arrays in one line of code:
<cfset a = ["paris","britney","lindsey"]>
<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:
<cfset s = {name="Raymond",age="Almost 35",weight="204",kids=["Jacob","Lynn","Noah"]}>
<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.)
Archived Comments
That is great! Now its time to add null support and var keyword anywhere in the function body :)
@radek: You really want 'var anywhere' ? Wouldn't removing the whole requirment for 'var' at all be better (i.e. unscoped variables in the function body are private by default) ?
+1 for Tom's suggestion!
I know a lot of people have been keen to see this improvement. Thanks to Adobe!
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.
@Ben,
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.
@Tony,
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.
@Ben:
" 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 ?
When it comes to backwards compat - folks - remember that we guys (bloggers, blog readers) are the minority in the community. The vast majority of folks aren't "in the know" and would be screwed over big time by compat changes. Trust me - it frustrates me as well, but Adobe has a -very- large customer base to think of here, so I don't blame them.
+1 for Tony's +1 for Tom!
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.
@Tom: switches will not solve the problem - backward compatibility is one thing correctly highlighted by Ben.
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.
@radek: But one flag to switch to the new functionality woul be good no?
@Tom:
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.)
Rather than enable this sort of thing via a global admin level switch, could it be enabled via a new attribute at the CFC level, i.e. <cfcomponent defaultlocalscope="true"> ?
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.
@Adrian: No - this one is fine. Byt as Brian gain poited correctly - how many switches there will be in CFAdmin in next 5 years?
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.
It meant to be: "But as Ben poited correctly again"...
I was seriously just complaining about not being able to this recently, so that in itself makes it a good thing.
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.
OK this works for me...
<cfscript>
var _init = {};
_init.testMe = {value="nudda3"};
return _init;
</cfscript>
... but this doesn't...
<cfscript>
var _init = {
testMe = {value="nudda4"};
};
return _init;
</cfscript>
even when I correct my manual typed in code and take the second semi-colon out! lol
Err, I was just going to say. It works fine for me when you do that, and remove the var. You can't use the var scope outside of a UDF. This code ran fine for me:
<cfscript>
var _init = {
testMe = {value="nudda4"};
};
</cfscript>
That is why the code came from inside a UDF. :)
Let me try it outside.
Same issue outside a CFC.
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
um - you are still on 800.
Thanks Ray... got the machine updated and ideed it does work again. Not sure what went wrong... updater didn't update for some reason first time. (I blame Vista because everyone likes to blame MS... lol)
Works now also.