Nodes in XLinq overload ToString() method to provide pretty-printed outer XML representation. At the same time nodes contain (familiar for MSXML users and new for .NET users) readonly Xml property, which returns raw (not pretty-printed) outer XML representation. At also at the same time casting element to a string returns element's value (string value with no angle brackets). There are also WriteTo() methods and Save() methods to complete the picture. I believe that's unnecessary confusing. Not only cast to string and ToString() do completely different things, but also there are many different ways of serializing nodes.
Here is how it works now:
XElement book = new XElement("foo",
new XElement("bar", "baz"));
Console.WriteLine(book.ToString());
Console.WriteLine(book.Xml);
Console.WriteLine((string)book);
The result:
<foo> <bar>baz</bar> </foo> <foo><bar>baz</bar></foo> bazActually I can live with it, but what do you think?
Another confusing thing is XElement.SetElement() method. Setting an element to a magic null value means removing the element. So this method either sets element's value or removes it depending on value provided. Hmmm, weird. That reminds me early C functions which used to be doing many different things depending on magic argument values. Are we back to realloc()-like design?
Leave a comment