ColdFusion 8's CFLoop Passes Array By Reference?
Posted December 27, 2007 at 3:09 PM by Ben Nadel
I was just having a little comment-conversation with Scott Bennett over on another post about the difference between CFScript and tag-based looping when I had a thought - if CFLoop tag attributes are only evaluated ONCE when the tag is initially fired (with the exception of the Condition attribute which does not use hash signs), does that mean that the Array attribute new to ColdFusion 8 passed arrays by reference or by value?
To test this, I set up a simple CFLoop scenario in which the array was truncated during loop execution:
- <!--- Create an array with four elements. --->
- <cfset arrGirls = ListToArray( "Sarah,Michelle,Sandy,Kat" ) />
-
-
- <!--- Loop over array. --->
- <cfloop
- index="strValue"
- array="#arrGirls#">
-
- <!--- Output current value. --->
- #strValue#<br />
-
- <!--- Flush data. --->
- <cfflush />
-
-
- <!--- Delete last item. --->
- <cfif ArrayLen( arrGirls )>
-
- <cfset ArrayDeleteAt(
- arrGirls,
- ArrayLen( arrGirls )
- ) />
-
- </cfif>
-
- </cfloop>
As you can see, we are passing the array, arrGirls, to the CFLoop tag using hash signs. Experience would lead us to believe that this means pass by value and is evaluated only once. During the loop, I then check for array items and delete from the end. Running this code, we get the following output:
Sarah
Michelle
CFERROR Has Fired With The Following Error - Array index out of range: 2 null
As you can see, when we get half way through the iteration, we have deleted enough tail items from the original array to cause the loop to run out of bounds. This would only happen if the array was passed to the CFLoop context by reference. Had it been passed by value, the ArrayDeleteAt() would NOT have affected the array stored internally to the CFLoop tag context.
What about the other way? That's how the CFLoop responds to modification by deletion, but how does it respond to modification by appending? In this next example, as we iterate over the array, we are going to be adding items to it:
- <!--- Create a small array. --->
- <cfset arrData = ListToArray( "data1,data2" ) />
-
-
- <!--- Iterate over the entire array. --->
- <cfloop
- index="strValue"
- array="#arrData#">
-
- <!--- Output current value. --->
- #strValue#<br />
-
-
- <!--- If the array is still small, append one item. --->
- <cfif (ArrayLen( arrData ) LT 5 )>
-
- <cfset ArrayAppend(
- arrData,
- "data#(ArrayLen( arrData ) + 1)#"
- ) />
-
- </cfif>
-
- </cfloop>
-
-
- <!--- Dump out the data array. --->
- <cfdump
- var="#arrData#"
- label="Final Data Array"
- />
When we run this code, we get the following output:
data1
data2
That's what is output during the CFLoop execution, but here's what the final CFDump reveals:
| | | | ||
| |  | | ||
| | | |
Interesting! Here's we have a little bit of a conflict! The CFLoop executed as if the array was being passed by value and was not acknowledging the modifications to the array that were made during the loop body. So now, we have one example that makes us think pass by reference and one execution that makes us think pass by value.
When you think about what both examples have in common, it starts to become clear what's going on - ColdFusion 8's new Array-CFLoop functionality is merely performing an index loop behind the scenes. When we write:
- <cfloop
- index="strValue"
- array="#arrGirls#">
-
- </cfloop>
... we can visualize this as working inside a ColdFusion Custom tag like this (pseudo code style):
- <cfloop
- index="ValueIndex"
- from="1"
- to="#ArrayLen( arrGirls )#"
- step="1">
-
- <cfset CALLER.strValue = CALLER.arrGirls[ ValueIndex ] />
-
- <!--- [EXECUTE BODY] --->
-
- </cfloop>
In this case, it doesn't matter if the array is being passed by value OR by reference - the underlying algorithm is only using the array length ONCE during initial tag execution. Then, going forward, throughout the body of the CFLoop tag, it is referring to the original array pointer; the passed reference is never used again.
This is what I theorize, but I think it makes sense.
Reader Comments
It's very possible that the code is using an underlying iterator to control the "loop."
Here's an example of how the iterator works...
<cfset array = ["a", "b", "c", "d"] />
<cfset iterator = array.valuesIterator() />
<cfloop condition="iterator.hasNext()">
<cfoutput>#iterator.next()#</cfoutput>
</cfloop>
@Shayne,
That could be. I just took a gander at some of the Iterator() functions in the Java layer (at least in the Java 2 docs, which are now old I suppose), it seems like the Iterators for things like ArrayList have iterators that will fail if the underlying array is modified. I can't remember off hand what type of collection is actually being used.
Regardless, it's safe to say that modifying an array within an array loop should be done with caution.
@Ben,
Very interesting I think your are pretty close, but it must be a little more complex than that or else it would not work with if there is not a variable already assigned to the array. For example If I do this:
<cfloop index="arrayitem" array="#listtoarray('Red,Green,Blue,Yellow,Black')#">
#arrayitem#
</cfloop>
There is probably some java logic in there that determines if there is already a variable assigned to this array in the "caller" variable scope and if there is it references that variable within the loop, otherwise it creates a temporary variable to be used within the array, as there is no way to manipulate the array data with array functions without having a variable assigned to it.
@Scott,
Good point and excellent catch. I totally forgot about inline array creation. It must be doing something very interesting though, because if it tried to create a variable for the array pointer, wouldn't that in and of itself create a copy of the array rather than the reference? Of course, I am sure in the underlying code, they can pick and choose when something is done by value vs. by reference (as with ArrayAppend() and ArrayPrepend()) - it's not like the ColdFusion code is built on top of ColdFusion code :) ... it's all built on top of Java.
Ummm yeah... that must be some other Scott Bennett cause I barely even know what those acronyms stand for.
@Scott,
Sorry, that must be some sort of spam... deleted.
Lol, at least he took the time to try and make that last comment not look like comment spam :)
@Scott,
Ugg, so irritating :)
