Matt Liotta:
Interesting! I have also found that variables created in loops are a big problem. For example, suppose you want to create an array of structures. You write a loop that creates a structure, assigns some keys, and then appends the structure to the array. How do you declare the structure as local to that function? Well you can't without resorting to some drastic measures.
Raymond Camden:
<cffunction ....> <cfset var tempStruct = ""> <cfset var data = arrayNew(1)> <cfset var x = 1>
<cfloop index="x" from=1 to=10> <cfset tempStruct = structNew()> <cfset tempStruct.foo = "moo"> <cfset arrayAppend(data,duplicate(tempStruct))> </cfloop>
Won't this handle it just fine?
I think so.
In my experiments, those variables which are scoped by the var term can later be returned to the calling function. I don't know how to test if they are returned by reference (and the var-scoping "deactivated" so that it persists after the function dies) or copied and returned by value -- nor do I know if there is any difference when you are talking about a value returned from a terminating function when that value was scoped to the function.
Barneyb:
It seems that Nathan found some contradicting evidence for the specifics of the CFQUERY return struct. Based on his research, it seem that the CFQUERY struct (and probably the other return structs from other tags) is immune to scoping issues, and the <cfset var cfquery = "" /> actually HIDES the return structure. So I guess those structures are outside the scope of race conditions because there can only be a single one alive at any time for a given request.
I think Nathan's experience would be explained if the internal/invisible scope used by CF for these types of return variables is the Variables scope. The following code produces the same results he claimed:
<cfcomponent>
<cffunction name="getEmployees">
<cfset var get = "">
<cfset var cfquery = "">
<cfquery name="get" datasource="cfsnippets">
select *
from employees
</cfquery>
<cfreturn get>
</cffunction>
<cffunction name="getLastExecutionTime">
<cfreturn Variables.cfquery.executionTime>
</cffunction>
</cfcomponent>The only change is scoping the cfquery to the Variables scope in getLastExecutionTime. When he added the <cfset writeOutput(cfquery.executionTime)> code to getEmployees, the scope it searched first was the local scope, where cfquery is a string not a struct. Had he scoped it like <cfset writeOutput(Variables.cfquery.executionTime)> then it returns just fine.
The big problem is that you can't scope things with a dot by using the var term. "var Variables.cfquery = ''" is illegal.
So I think there *is* an issue about race conditions when using these variables, and I don't think it can be solved by scoping them. It seems the best option is to immediately transfer the value you want to preserve into a properly scoped variable and then pass that around.
--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: 310 478 6648
f: 310 235 2067----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
