Reminds me of the regrettable mistake that was E4X. I used it when developing TomTom Home on xulrunner, and its helpful "blurring" of XML and XMLList was no help at all, a misguided attempt to oversimplify something that just ain't that simple. I couldn't believe they designed it that way on purpose. It made JavaScript seem more like PHP.<p><a href="http://www.morearty.com/blog/2007/03/13/common-e4x-pitfalls/" rel="nofollow">http://www.morearty.com/blog/2007/03/13/common-e4x-pitfalls/</a><p>5. E4X intentionally blurs the distinction between XML and XMLList<p>When you begin to learn E4X, you learn that there are two main data types, XML and XMLList. That seems simple enough. But then after a while, you start to notice places where it seems like the “wrong” type is being used, or where impossible things are happening.<p>var mydocument =
<root>
<rabbit name="Brownster Johansson McGee" />
</root>;<p>// 'mydocument.rabbit' means to get a list of ALL <rabbit>
// nodes, so myPetRabbit must be an XMLList, right? But
// I'll call my variable 'myPetRabbit', not 'myPetRabbits',
// because I happen to know that I have only one pet
// rabbit.<p>var myPetRabbit:XMLList = mydocument.rabbit;<p>// What's her name? Hey wait a minute, "her" name?
// Why does this next line work? Isn't myPetRabbit an XMLList?
// What does it mean to get an attribute of a list??<p>trace(myPetRabbit.@name);<p>The reason this works is that E4X intentionally blurs the distinction between XML and XMLList. Any XMLList that contains exactly one element can be treated as if it were an XML. (Furthermore, in this example, even if ‘myPetRabbit’ held a list of more than one node, myPetRabbit.@name is still a legal expression; it simply returns a list of all “name” attribute nodes of all of those elements.)<p>In fact, if you search the E4X spec (PDF) for “blur”, you will find 15 usages of the phrase “… intentionally blurs the distinction between….”<p>For example, another place where this blurring is evident is in the behavior of XMLList.toString(). As the Flex docs say:<p>If the XML object has simple content, toString() returns the string contents of the XML object with the following stripped out: the start tag, attributes, namespace declarations, and end tag.<p>If the XML object has complex content, toString() returns an XML encoded string representing the entire XML object, including the start tag, attributes, namespace declarations, and end tag.<p>So if an XMLList contains <node>hello</node>, then toString() will return "hello"; but if the list contains <node>hello</node><node>goodbye</node>, then toString() will return "<node>hello</node><node>goodbye</node>" (not "hellogoodbye"). Presumably this decision was made in an effort to achieve “do what I mean” behavior, where the output would match what developers most often intended; but personally I find it a little confusing. If you really need the full XML version of an XMLList that contains simple content, use toXMLString() instead of toString().