Osborn: The basic syntax for all three types of queries is really the same in C#. How should we think about the separate pieces that we need to download? DLinq, XLinq and the Standard Query Operators. Are they all just part of the same package? Why are you making that distinction in the way you're presenting it?
Hejlsberg: It's a question of classes versus instances. There's the class of problem we're solving, which is the ability to query objects, or object wrappers, really, in a sense, because they don't necessarily have to be existing instances of objects. That class of problem is what language integrated query is about. It's the notion that, given a class declaration, given an instance of some class, you can write a query against it where you refer to its properties and the properties of that, and whatever.
And you're not necessarily actually holding real instances of real objects at that point, because objects can be proxies for things. That's how O-R [object relational] mappings work, right? And that's what gives you the ability to write what appears to be a query against all of the orders in my database, when none of them have been materialized yet. So because objects are very powerful in that way, you can actually expressively do a bunch of stuff.
But then underneath, we can implement it through an O-R mapping. So what you're seeing, really, there's the class of problem we're solving, and then you're seeing specific instances of that class of problem. One is this API we call the Standard Query Operators, which just says here is a relationally complete, hierarchical query language for anything that implements
And by the way,
every array or collection in .NET does. And that's sort of the super low barrier to entry to this system. It's the instant gratification effect. Bam, you can query any collection you have, any array you have in memory, and so forth. But then we also say well, that's great, but now there's relational data, right? Well, relational data, we could sort of do the dumb thing and just suck the whole table into memory and then use the standard query operators to query it, but that's obviously not acceptable.
So here we have another instance of the problem we want to solve where we actually want different execution semantics. Instead of executing the query in memory, we want to capture an expression tree, and remote that [expression tree] to the database in SQL form. So effectively, [we want to] capture an expression tree, translate it to SQL, send that to the database, and then create objects as the results come back. And illusion is that "Hey, the query looks exactly the same," but boy, the way it executes is totally different.
And then for XML, well, that's a different world again because now you're talking about a different type of data structure. You have an XML object model, which has looser typing than CLR objects, and different semantics and so forth. But the base query language still applies.
So that's how you should think of them. They're just different instances of the same class of problem. But the subtle difference is that, well, now APIs can be query-enabled, just like they can be persistence-enabled, or remoting-enabled. Querying becomes a new
capability in an API.
Osborn: So what you're getting with the different packages is different sets of APIs for carrying out those--
Hejlsberg: They're different APIs that are query-enabled, yes. So that's an attribute of the APIs, if you will.
Osborn: Gotcha. A couple people have quoted you as saying you think you've solved 90 percent of the problems out there. What's the other 10 percent?
Hejlsberg: [laughs] You mean like in computing in general?
Osborn: In relation to query. [The implication, I think, is that] there is still a need for some specialized query languages [whose functionality] we couldn't approach yet through what's in C#.
Hejlsberg: Well, I think we're certainly trying to cast a very wide net here, and capture as much as we possibly can. But I don't expect this to be the be-all, end-all of query as a concept. Well, obviously SQL's going to be around for a good, long time. And I'm not naïve in thinking that we're going to get rid of SQL or get rid of XQuery or whatever. No, no, no. We're going to be complementary to those technologies.
We're going to be a great tool that you're going to have available if you're coding on the .NET framework. But this brings to mind another design principle I have whenever I'm involved in designing APIs.
For example, with DLinq it's great to be able to write language-integrated query because it's going to get you there quicker, faster, you're going to be more productive, and so forth. But sometimes you're going to want to write some esoteric SQL query that uses some user-defined function, calls some stored procedure, or whatever. You know, there's always some reason why occasionally you have to do that. And part of the DLinq API is what you could think of as the SQL escape hatch. So you can write a language-integrated query, but we also have a method in there called
ExecuteQuery that takes a string that is a SQL query.
And then you get to say the type of the result using a type parameter. So you can say
ExecuteQuery<Customer>("select * from customers where ...") and call some user-defined function in the SQL query. And then we will treat the result of that as instances of type
Customer. So you still get all of the other DLinq features, such as referential identity, change tracking, and the ability to submit changes back to the server, and so forth.
I was also involved, earlier in my career at Microsoft in designing the Windows forms APIs. And in there, for example, there's also an escape hatch that allows you to get the underlying window handle, and just call User32.dll functions directly, because sometimes you just need to. There always has to be an escape hatch that gets you back to the underlying technology.
You know, all too often, encapsulations think that their purpose in life is to hide. That is not their purpose. Their purpose is to make something easier to use, but not to hide what's underneath.
Osborn: Now that you have achieved all of this here, what's next? What's the new frontier?
Hejlsberg: Well, let's see, next is, ship C# 2.0, and then ship 3.0.[laughs]
Osborn: Yeah, I should ask you about the timeframe. You are releasing a CTP--
Osborn:--at the show [PDC 2005] for people to play with.
Hejlsberg: Yes, and on the Web too. So it's not just for show attendees. Anybody can download it and put it on top of Beta 2. So if you installed the Whidbey beta of Visual Studio 2005, Beta 2, then you can download the LINQ project tech preview and install that right on top. It's just a little six-megabyte download. It has lots of documentation in it: an overview of the LINQ project, the C# 3.0 language specification, the standard query operator spec, DLinq, XLinq, and lots of examples, so people can really just install it and sit down and completely understand--
Osborn: Yeah, I was impressed with the 101 examples your team has posted.
Hejlsberg: Yeah, I'm so happy we have that little app, because it is so darn useful for people. Because programmers want to see code, and they want to see the results of writing the code. And that is exactly what that thing does.
Osborn: Sure. So there will be a beta; the beta's scheduled pretty much in line with the Orcas schedule, do you think? [Ed.: Orcas is the next major release of Visual Studio, expected sometime in the first half of 2007.]
Hejlsberg: Well, we're targeting the Orcas wave of products with this technology, yes. That's about as specific as I can be at this point. Once we have the final RTM version of Visual Studio 2005, we will refresh the technical preview of the LINQ project to sync with that, so you can use LINQ, the preview, on top of the shipping product. So that much, we know that we're going to do.
But I can't tell you when the Orcas wave of products exactly is going to be, and so forth. And I can't give a you 100 percent guarantee either that [all of the announced C# 3.0 and LINQ extensions] are going to be in there, but that is certainly what we're aiming for.
Osborn: To summarize, what would you like people to remember about--what should programmers be doing with 2.0 and 3.0 right now?
Hejlsberg: With 2.0, I would urge them to take advantage of generics and the stronger typing that you get in your programs. It's such a win-win situation. It's like having your cake and eating it too. So I would urge people to take advantage of that in their apps. With 3.0, I think it's important to take a look at the technology preview that we're giving out here, because this really gives a glimpse into the future of what's happening.
And also, I would love to get feedback on this technology. We're really, I would argue, doing some deep innovation here in the language. And that means we're treading new ground, and we need feedback more than ever on whether we're going in the right direction.
Osborn: What's the best way to do that, for people who want to get involved?
Hejlsberg: When you install the LINQ preview, there are links in there to our forums on MSDN. Many of our team members have blogs that--there are lots of opportunities for feedback that way. We also have our ladybug bug-tracking system where you can actually enter bugs on products and so forth. So, there are lots of opportunities to give feedback.
Hejlsberg: Or email, for that matter.
Osborn: Thank you very much. I hope we can talk again in five years. [laughter]
John Osborn is a senior editor with O'Reilly Media, Inc., responsible for Windows and .NET developer books, PDFs and other content.
Return to the ONDotnet.com.