Ask a Jedi: Listing all var scoped variables
Dale asks about var scoped variables:
I think the answer is no, but it seems strange. All variables go into a scope somehow.But if I declare 5 variables as var within a function, coldfusion knows that they are only for that function, but how can I get to them? Is it possible to dump all var variables for a given function? Where are they hiding, are they a struct withing some other scope.
If I dump all the scopes, variables, this, sesssion etc would they simply not exist.
I normally use <cfset var local = structNew() />
Which gets around this, but really wondering where the variables live.
You are correct. Var scoped variables are "special" and currently there is no way to enumerate them in ColdFusion. That is exactly why some people use a local struct as you have described above. Yes, ColdFusion does know about them, and yes, it is a bit odd that they don't have a proper scope, unlike every single other variable out there.
Personally I don't like using a struct for my var scoped variables. It just seems like too much to type. Of course the flip side is that I'm typing more var scopes. I also kind of like seeing the var scope lines as it helps remind me what is going on inside my function.
Comments
I wouldn't consider the dump you used as valid though since it isn't actually documented. I'm sure it works - but I'd be wary of pushing production code with anything that wasn't _supposed_ to work (ie, documented). That being said, I love your private = {}. I obviously new about short hand notation for structs in CF8, but it never occurred to me use them for _blank_ arrays or structs. Nice!
# Posted By Raymond Camden
| 7/3/07 11:07 AM
@Sam, I really wouldn't have CF create a struct for each and every function and for each and every invocation of that function. You realize a struct is a heap-based java object that has to be created and released each time, correct?
Further, I don't see how you have "less chance" of a variable not being in VAR scope. Forget to VAR a cfquery name and your query will still hit the cfc's scope, added struct or not.
From a cumulative performance standpoint, this is a bad thing.
Further, I don't see how you have "less chance" of a variable not being in VAR scope. Forget to VAR a cfquery name and your query will still hit the cfc's scope, added struct or not.
From a cumulative performance standpoint, this is a bad thing.
# Posted By Michael Long
| 7/3/07 12:13 PM
Yeah, I agree with your thoughts about undocumented features and it being valid. Though, really cfdump should not be used in production IMO.
The private var scope idea I read about in the comments of this entry (see Matthew Lesko's and Todd Sharp's comments):
http://www.firemoss.com/blog/index.cfm?mode=entry&...
The private var scope idea I read about in the comments of this entry (see Matthew Lesko's and Todd Sharp's comments):
http://www.firemoss.com/blog/index.cfm?mode=entry&...
# Posted By Sam Farmer
| 7/3/07 12:15 PM
I use cfdump in production - but only for error emails. It is handy to have a dump of all the data for the current request.
# Posted By Raymond Camden
| 7/3/07 1:11 PM
@Michael -- My tests show there is no real time difference when using a stucture (I'll post the test on my blog tomorrow). Still, I do only use a private structure when I need it.
As for less chance if you have a big function, say, 50 lines plus, and you're half way through it and working on a loop, it is much easier to add cfloop index="private.i" than it is to do index="i" and go to the top of the function and do cfset var i = 0. Thats all.
As for less chance if you have a big function, say, 50 lines plus, and you're half way through it and working on a loop, it is much easier to add cfloop index="private.i" than it is to do index="i" and go to the top of the function and do cfset var i = 0. Thats all.
# Posted By Sam Farmer
| 7/3/07 1:13 PM
@sam, Still don't buy the "less chance" argument. Yes, you just saved yourself ten seconds... but at the expense of a minor performance hit server-side each and every time the function is called from now on. Those hits are small, but implement them as a pattern throughout the system and sooner or later they start to add up. And usually just when things start to scale.
And I take it back about saving ten seconds, as you now need to type "private." in front of every variable reference. Not to mention the fact that if you now FORGET to type "private." in front of some variable name you've now blown the VAR scope again, but for a different reason.
Just a bad coding practice in my book.
And I take it back about saving ten seconds, as you now need to type "private." in front of every variable reference. Not to mention the fact that if you now FORGET to type "private." in front of some variable name you've now blown the VAR scope again, but for a different reason.
Just a bad coding practice in my book.
# Posted By Michael Long
| 7/3/07 3:05 PM
@Ray: Ah, yeah, good point. I do that as well. Very handy.
# Posted By Sam Farmer
| 7/4/07 12:54 PM
@Michael
I don't use the private or local convention myself, but I've tempted to consider adopting it, precisely because it allows for all of your variables "looking" scoped. If you have any variable that has less than 2 words, you know it wasn't scoped correctly.
And I think you've posted on another blog about some other programming concern where someone was using structs, and you warned about performance.
First: most people are not scaling to the point where performance (outside of really poorly designed algorithms) really matters. If the struct helps to design cleaner code, eliminating it for performance is premature optimization.
Second: adding a struct really doesn't add that much in way of processing. I ran a very basic test (I know -- looping is a bad testing mechanism). But creating a million structs seems to take around 11 seconds or less on average. So, that's around 0.01 milliseconds per struct. Only Google, Amazon, or Ebay really needs to worry about shaving off that kind of time.
I don't use the private or local convention myself, but I've tempted to consider adopting it, precisely because it allows for all of your variables "looking" scoped. If you have any variable that has less than 2 words, you know it wasn't scoped correctly.
And I think you've posted on another blog about some other programming concern where someone was using structs, and you warned about performance.
First: most people are not scaling to the point where performance (outside of really poorly designed algorithms) really matters. If the struct helps to design cleaner code, eliminating it for performance is premature optimization.
Second: adding a struct really doesn't add that much in way of processing. I ran a very basic test (I know -- looping is a bad testing mechanism). But creating a million structs seems to take around 11 seconds or less on average. So, that's around 0.01 milliseconds per struct. Only Google, Amazon, or Ebay really needs to worry about shaving off that kind of time.
# Posted By Toby Reiter
| 7/5/07 4:33 PM
Michael --> It may seem like a bad practice but it's to deal with the bass ackwards way CF approaches scoping for variables (local, global; not CF's "scoping" which isn't scope but something else). CF screwed it up and now we're just trying to deal with the mess. I also disagree with the idea that it's a performance hit that actually matters. It's like the old overly academic argument that you should only use CFOUTPUT around exactly what needs to be generated. I mean, come on, CF variable scopes are just structures in themself. It's doing it all the time. This time it just limits that struct to the method call. What's the diff between 5 freestanding variables and a struct with 5 keys? If there actually is a difference in perforumance I can't imagine it as anything other than nearly negligible. And, to step back from it, OO is well know as creating more overhead... so if you're that worried about performance just stick to the old school procedural CF stuff then. I've written apps with a few thousand concurrent users that, for example, have trim() EVERYWHERE and it didn't cause any issues. I don't see how a few extra structs should be any different than an extra 5, 10, 30 trims.
---> "VAR a cfquery name" : Does anyone have an example of how to do this? I haven't seen it before. Thanks.
---> "VAR a cfquery name" : Does anyone have an example of how to do this? I haven't seen it before. Thanks.
# Posted By Allen
| 4/23/08 5:22 PM
@Allen - its simple. If the query is named foo, you just do var foo = "".
# Posted By Raymond Camden
| 4/23/08 8:10 PM
Thanks! I was off in la-la land trying to find an attribute in the cfquery tag and trying <cfquery name="var qName"... Just set it right before the query and you're set. Sweet.
# Posted By Allen
| 4/23/08 8:33 PM
<cfset var private = {}> (replace {} with StructNew() for pre-8)
and then use the private structure for all my var variables. To me this is a) consistent with how CF works and b) leads to less chance of having variables in cfcs that are not in the var scope and c) means I can create a new var variable half way through a function.
You can dump the var scope with this:
<cfdump var="#getPageContext().getVariableScope()#">