-
-
-
3. Re: CF creating spurious variables
Adam Cameron. Feb 26, 2011 4:47 AM (in response to BKBK)Thanks. That's what we're seeing too. I know of one person who is not seeing this though. Weird.
--
Adam
-
4. Re: CF creating spurious variables
Adam Cameron. Feb 26, 2011 4:54 AM (in response to Adam Cameron.)I've created a bug report:
http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html#bugId=86496
--
Adam
-
5. Re: CF creating spurious variables
BKBK Feb 26, 2011 4:58 AM (in response to Adam Cameron.)Peculair find, indeed. A Google search revealed just one instance of the term IMPLICITARRYSTRUCTVAR0 on the web.
-
6. Re: CF creating spurious variables
Adam Cameron. Feb 26, 2011 5:16 AM (in response to BKBK)What's even more interesting is that when I googled "___IMPLICITARRYSTRUCTVAR0" the other day... nothing came back. Now Ben's article; and... very quick of google indeed: this thread; a mirror of this thread; and another coupla mentions of it too.
--
Adam
-
7. Re: CF creating spurious variables
BKBK Feb 26, 2011 7:02 AM (in response to Adam Cameron.)Clearly a bug. I have been able to reproduce it -- always! (Note, however, my CF version above.)
I have learned something new from this exercise. I never realized until now that <cfloop item="myKey" collection="#myCollection#"> adds myKey to the variables scope!
The IMPLICITARRYSTRUCTVAR0 never occurs when you use this code:
<cfset st.foo1 = "foo1">
<cfset st.foo2 = "foo2">
<cfloop item="sKey" collection="#variables#">
Key:<cfoutput>#sKey#</cfoutput><br>
<cfdump var="#variables#">
<hr />
</cfloop>The IMPLICITARRYSTRUCTVAR0 never occurs when you use this code:
<cfset st = {foo1 = "foo1", foo2 = "foo2"}>
<cfloop item="sKey" collection="#st#">
<cfdump var="#variables#">
<hr />
</cfloop>However, the IMPLICITARRYSTRUCTVAR0 always occurs when you use this code:
<cfset st = {foo1 = "foo1", foo2 = "foo2"}>
<cfloop item="sKey" collection="#variables#">
<cfdump var="#variables#">
<hr />
</cfloop>Apparently, when you use the new curly-bracket notation for structs and you loop through the variables structure, ColdFusion adds the extra key IMPLICITARRYSTRUCTVAR0 to the variables structure.
-
8. Re: CF creating spurious variables
Adam Cameron. Feb 26, 2011 7:54 AM (in response to BKBK)Yeah - re the cfloop/item thing - it's not some sneaky iterator or anything: it's literally just a string holding the key name for each key in turn. It's like doing a list-loop over a structKeyList().
--
Adam
-
9. Re: CF creating spurious variables
Adam Cameron. Feb 26, 2011 8:00 AM (in response to BKBK)Oh yeah, forgot to say. I don't think it's anything to do with the loop, per se. I'm on a train to the pub to watch England v France (Six Nations), so cannae check, but you should just be able to do this:
st = {};
writeOutput(structKeyExists(variables, "___IMPLICITARRYSTRUCTVAR0");
--
Adam
-
10. Re: CF creating spurious variables
BKBK Feb 26, 2011 9:45 AM (in response to Adam Cameron.)Adam Cameron. wrote:
Oh yeah, forgot to say. I don't think it's anything to do with the loop, per se. I'm on a train to the pub to watch England v France (Six Nations), so cannae check, but you should just be able to do this:
st = {};
writeOutput(structKeyExists(variables, "___IMPLICITARRYSTRUCTVAR0");
Say what? Computer says yes! Nice counterexample!
Gets me thinking perhaps Javaman forgot to take out the placeholder for index 0 after the design phase. The code
<cfset st = {}>
<cfoutput>
structKeyList(variables): #structKeyList(variables)#<br>
isDefined("variables.___IMPLICITARRYSTRUCTVAR0"): #isDefined("variables.___IMPLICITARRYSTRUCTVAR0")#
</cfoutput>gives the result
structKeyList(variables): ___IMPLICITARRYSTRUCTVAR0,ST
isDefined("variables.___IMPLICITARRYSTRUCTVAR0"): YESBut then again, the variable ___IMPLICITARRYSTRUCTVAR0 is nowhere to be found in <cfdump var="#variables#">
-
11. Re: CF creating spurious variables
Adam Cameron. Mar 2, 2011 11:57 AM (in response to BKBK)Yeah. Sadly I think they have put specific code into dump.cfm to suppress output of that variable.
One would think that of they were going to those lengths, their time might be better spent simply fixing the issue instead.
Oh well: the bug is logged. Very little of our code needs refactoring to avoid this, so I'm not that fussed.
--
Adam



