Disclaimer: I do not work for Microsoft, but I am a Microsoft MVP. The following is all derived from public information, and any inferences or extrapolations are entirely the work of my imagination, and is not something that I know that Microsoft is working on. If I knew Microsoft was working on things like this, it would be covered under my non-disclosure agreement, and you wouldn’t be reading about it here. If you like (or hate) these ideas, let Microsoft know about it.
The final version of.Net 2.0 is just about to be released, and we are already starting to get bits and pieces of what they are toying with for the next version with the announcement of the LINQ project during the PDC. LINQ is the code name for extensions to the .Net framework that extends C# and VB with native language syntax for queries and other functional style programming constructs. XLinq is an implementation of Linq designed around creating a new API around XML. The idea is to create a more natural API for creating and manipulating XML. Think of it as a more modern version of the XML DOM. Here are some examples from the XLinq documentation:
Your typical DOM based approach to building an XML document:
XmlDocument doc = new XmlDocument();
XmlElement name = doc.CreateElement("name");
name.InnerText = "Patrick Hines";
XmlElement phone1 = doc.CreateElement("phone");
phone1.SetAttribute("type", "home");
phone1.InnerText = "206-555-0144";
XmlElement phone2 = doc.CreateElement("phone");
phone2.SetAttribute("type", "work");
phone2.InnerText = "425-555-0145";
XmlElement street1 = doc.CreateElement("street1");
street1.InnerText = "123 Main St";
XmlElement city = doc.CreateElement("city");
city.InnerText = "Mercer Island";
XmlElement state = doc.CreateElement("state");
state.InnerText = "WA";
XmlElement postal = doc.CreateElement("postal");
postal.InnerText = "68042";
XmlElement address = doc.CreateElement("address");
address.AppendChild(street1);
address.AppendChild(city);
address.AppendChild(state);
address.AppendChild(postal);
XmlElement contact = doc.CreateElement("contact");
contact.AppendChild(name);
contact.AppendChild(phone1);
contact.AppendChild(phone2);
contact.AppendChild(address);
XmlElement contacts = doc.CreateElement("contacts");
contacts.AppendChild(contact);
doc.AppendChild(contacts);
The XLinq way:
XElement contacts =
new XElement("contacts",
new XElement("contact",
new XElement("name", "Patrick Hines"),
new XElement("phone", "206-555-0144",
new XAttribute("type", "home")),
new XElement("phone", "425-555-0145",
new XAttribute("type", "work")),
new XElement("address",
new XElement("street1", "123 Main St"),
new XElement("city", "Mercer Island"),
new XElement("state", "WA"),
new XElement("postal", "68042")
)
)
);
You can see how the XLinq code has a more natural feel to the API, than the older XML-DOM (side note: yes, these examples are lame, because they do not have the one thing that all good XML fragments should have, namespaces. Part of the reason is that the way namespaces are declared in the current version of XLinq doesn’t feel as natural as the rest of the API (IMHO). So for now, just ignore the namespace issue. I’m sure that with the help of folks like us, XLinq will have an implementation of namespaces that feels as natural as the rest of the API).
The VB Team has taken XLinq one step further in their desire to create a more natural XML API, and add something called XML Literals. Instead of having to actually explicitly declare the object types using the VB constructs, they have simplified to just having to place the actual XML inline with your code:
Dim contacts As XElement = _
<contacts>
<contact>
<name>Patrick Hines</name>
<phone type="home">206-555-0144</phone>
<phone type="work">425-555-0145</phone>
<address>
<street1>123 Main St</street1>
<city>Mercer Island</city>
<state>WA</state>
<postal>98040</postal>
</address>
</contact>
</contacts>
This is the exact same code as in the other examples, except that the VB compiler “sees” the XML, and then creates the equivilant XLinq commands for you. The net result is that a VB programmer doesn’t even have to know how to create the XLinq objects by hand. The VB compiler handles it for them, thus making it easier for the VB developer to create XML. But what if you didn’t have static XML, and just needed templates to help you generate the final XML. Well, they have you cover there too, with the concept of expression holes that can reside within your XML declarations:
Dim contacts as XElement = _
<contacts>
<%= _
Select _
<>
<!-- contact -->
<name><%=CStr(c.name(0))%> </name>
<%=c.phone %>
<address><%= c.address %> </address>
</>
From c In contacts
%>
</contacts>
I don’t know about you, but that sure looks a little familiar. Once I saw that little bit of code, well my mind started to add other little pieces of existing knowledge.
Since VB XLinq XML Literals look a lot like old school ASP programming, and that was so sucessful, why not bring it into the 21st century, and instead of generating sloppy HTML, do something more useful. No, I’m not talking about XHTML (but close). I’m talking about using VB XLinq XML Literals to generate XAML. XAML is just a declarative way to wire up .Net objects, and the most popular use of XAML has been the Windows UI realm (aka Windows Presentation Foundation, aka Avalon). In the future, could we see VB programmers writing classic ASP style code to generate Windows applications? Classic ASP was a very easy (and fast) way to generate websites. I’m not saying that I’d want to do that in an enterprise environment, but I could definitely see the “Hobbyist Programmer” doing something like this. And it would also solve “where is Microsoft’s replacement for classic VB” question.
I don’t know if all of this is 100% possible, but it sure looks probable. Don’t even get me started on using something like this in combination with Monad (the new Windows Command Shell). Combined together, it could be all that Windows Scripting Hosting wanted to be, but never was.