The Occasional Danger Of ColdFusion's Automatic Data Type Conversion
ColdFusion does a lot to help you out as a programmer. In that vein, ColdFusion will often convert data types for you as it sees it necessary. Unfortunately, that can come back to bite you if you are not careful. This morning, I spent a solid 45 minutes trying to debug an XML error because it didn't occur to me that I was getting a little extra help. To demonstrate, here is an example of the problem I was running into:
<!--- Create an XML document. --->
<cfxml variable="xmlData">
<data>
<node>Ben Nadel - Kinky Solutions</node>
</data>
</cfxml>
<!--- Check equality of DUPLICATE nodes. --->
<cfif (xmlData.data.node EQ Duplicate( xmlData.data.node ))>
Equal!
<cfelse>
Not Equal!
</cfif>
As you can see here, I am duplicating a given XML node and then comparing it back to the original. Now, if you program in other languages like Java or Javascript, because an XML node is a complex object, you would assume that this would output "Not Equal!" since we are comparing an object to a clone of itself. However, when I run the above code, I get the following output:
Equal!
What I forgot was that when performing equality tests in ColdFusion, ColdFusion tries to convert the objects in question into simple values and then compare the rendered simple values. So, when comparing two XML nodes, the pseudo code for this is actually:
ToString( XmlNodeA ) EQ ToString( XmlNodeB )
When we keep this in mind and think again about comparing an XML node to the Duplicate() of itself, we realize that of course it will always be equal since the string equivalent of the two nodes will always be the same.
This type of automatic data type conversion can be awesome; but, if you forget that it is happening, it can come right around and bit you in the butt! Now, I am not arguing against this - I love that ColdFusion will do this for us; I am just saying that it is important to keep this behind-the-scenes functionality in mind.
Want to use code from this post? Check out the license.
Reader Comments
Oh yes, I've had this happen to me too. Here's one I encountered:
I had an application where I wanted to display a price value. If the price value had no cents, but the user typed in an ending ".00", I wanted to remove this, and just display the whole dollar amount (e.g. $25 instead of $25.00). So being the smart programmer, I just looked for a ".00" as the last three characters and dropped them if it existed. I tested it, and if worked just as desired.
The first day in production, someone calls and says they keep entering $6,000 but it shows up on the web as "$6,". What!! I test this myself, and yep, the last three zeros are getting dropped. I scour the code, write a little test, and CF keeps thinking ".00" is equal to "000". Of course any human can see these strings are not equal.
They may look like unequal strings to me, but to CF they're the same. Why? Well, CF looks at the first ".00" and decides that this can be interpreted as a numeric ZERO, so that's how it treats it, as numeric. Then the "000" can be interpreted as a numeric ZERO too, so ZERO equals ZERO and those last three zeros are going to be dropped from the value and "$6," is going to be displayed.
The solution is to use the compare() function, which does a string comparison.
@Steve,
Yeah, "zero" can be tricky cause it can also convert it into a numeric date/time. When it does things like that, I think you can get odd things like ".00" equaling "0AM".
Compare is one way to handle that... I tend to prefer int() if not lsnumberformat() or numberformat(). But for that matter, even rereplace(string,"\.00$","") should work fine.
So how did you go about reliably checking whether one XML node is the same as another after all?
+1 for Helgi's question: how do you check if two XML node objects are actually the same instance?
@Helgi, @Martijn,
Through ColdFusion directly, there doesn't seem to be a create sense of referential quality of objects. But, check out the comments on this post:
www.bennadel.com/blog/2077-Creating-ColdFusion-Proxy-Components-With-ColdFusion-9-s-GetFunctionCalledName-.htm
People were passing around some ideas on how to dip down into the Java layer to look at the core Object values and hash codes and what not. I haven't tried those approaches yet; but, under the XML is Java; and behind the Java is the core Object, which is what I think people were getting at. Worth taking a peek-see.
@Ben,
I tried comparing node references by looking at their java.lang.System.identityHashCode() values. I turned out that two references to the same node have different hashcode values.
It appears that XML nodes are passed by value, not reference. This is somewhat surprising, because the XML document is passed by reference: if you make a change to a document, all references to the document see this change.
This makes me wonder: if you add a flag attribute to a node through one reference, would it become visible through the other reference, because the underlying document has changed?
I actually saw that you use a flag attribute to be able to determine a node's position index, to be able to delete it- in your XDom.cfc. In XDom however, you retrieve the node and its siblings through a new XmlSearch() and then you iterate through the results, checking for the existence of the flag attribute. It would be interesting to see if adding such a flag would also enable us to see if two node variables point to the same node in a document.