Monthly Archives: May 2007

VB Runtime agility, Orcas and new platforms

One of the problems that we’ve run into when trying to get new platforms such as the Compact Frameworks or Silverlight to support Visual Basic is getting the VB runtime supported on the new platform. The VB runtime, besides having a bunch of user functions such as Left and MsgBox and such, contains a number of language helper functions that are required for the correct functioning of the language. For example, when you convert an Integer value into a String value, we emit a call to a helper that does the conversion for you, since there is no native IL instruction for this. The number of situations where we emit helper calls isn’t huge, but there are some core features of the language that just won’t work without them. This is why there’s been no officially supported way to remove the reference to Microsoft.VisualBasic.DLL.

More than the language, though, the problem is that the compiler won’t work without the helpers, either. Basically, the VB compiler will just crash when it fails to find a VB runtime helper. Even if you’re careful to avoid features that don’t use helpers, it still doesn’t mean you can just run without a reference to Microsoft.VisualBasic.DLL–there are still many cases where we sanity check for helpers even if we aren’t going to use them. Which means that even if you managed to figure out how to get the compiler to not reference Microsoft.VisualBasic.DLL, it was likely that lots of things aren’t going to work.

As we faced the prospect of more and more platforms starting to support .NET, we realized that we needed to do something about this situation in Orcas. So we did a feature we’ve been calling “runtime agility.” The runtime agility work basically enables new platform developers to compile without a standard reference to Microsoft.VisualBasic.DLL and we’ll only barf on missing runtime helpers if you try to use a feature that requires them. And when we do barf, we give you a nice error message telling you what helper was missing instead of just crashing. You can also redirect the VB runtime reference to another DLL if you’re building a new one for your platform. For platform developers, this means that they can more easily develop a VB runtime DLL for their platform without having to stub in a bunch of helpers that they don’t support. And, yes, if you really want to run without a VB runtime, you can now do that.

This switch is only supported on the command-line for Orcas–there’ll be no UI expression of it. The switch is “/vbruntime” and should show up, I believe, in Beta2.

What does the PDC cancellation mean for VBx?

As many people know by now, Microsoft has decided to reschedule the PDC that was planned for later this year. This was very disappointing for me personally, since I was looking forward to seeing a bunch of the people that I usually see there and was one of the consolations I had for myself for not being able to go to MIX. It also means that our plan to talk more about VBx at the PDC is going to have to be shifted around. Not clear where/when our focus is going to move to, but stay tuned, we should have more information shortly…

Partial Methods in VB

As is always the case in a major release, there are a number of smaller features that don’t get very publicized because they’re not as big or sexy as the major features. One that someone asked me about privately in email was partial methods. VB will support them in pretty much the same way that C# does. In fact, rather than writing a big, long entry about it, you could just check out Scott Wisniewski’s excellent entry on them. You can also check out Wes Dyer’s excellent entry on them for C#.


How’s that for lazy?


Updated 05/30/2007: Somehow I’d missed the fact that one of our own wrote a whole entry on them on the VB blog! Eek! My apologies to Scott for missing his entry and check it out!

Mutable and immutable anonymous types, and keys

About a month ago, the C# team announced that they were making anonymous types immutable in C# 9.0. The issues with mutable anonymous types are pretty well described in Sree’s blog entry, but what it boils down to is this: in several places in LINQ, anonymous types are used as keys for things like grouping and filtering. For example, if you group customers by state and country, then the grouping is done on a composite key made up of the State field and the Country field in an anonymous type. To enable keys to be used to do grouping efficiently, they have to expose a stable hash value. That is, once a key has been constructed, it always needs to return the same hash value.

The problem was that anonymous types base their hash value on the hash values of the constituent members of the type. If those values are mutable, then that means that the hash value is mutable. Which means that the hash value might not be stable, which means that it might be possible to really hork up LINQ queries by accidentally changing keys during an operation.

In looking at this problem, though, we didn’t want to throw the baby out with the bathwater. Anonymous types are somewhat limited at the moment because they cannot be named, but you can use late binding to work with them even outside of the context in which they were declared. And future features that we’re interested in exploring, such as nominal anonymous types and dynamic interfaces, may make anonymous types even more useful. As such, it seemed too drastic to simply make them immutable, especially because this would be a one-way decision–once they were immutable, compatibility would make it extremely difficult to make them mutable again in the future if it become more desirable to do so.

At the same time, it occurred to us that the problem we’re dealing with here–generating hash values–is one that applies to many situations, not just anonymous types. Generating hash values is a common operation for types, and making it easier to do that right seemed to be a win. So instead of changing the way anonymous types work, we’ll be introducing in Beta 2 a way to more easily generate a correct hash value from a type. For Orcas, this will be limited to anonymous types, but beyond Orcas, we’d like to generalize this to all types.

In Beta 2, you will be able to specify a Key modifier on a field of an anonymous type (i.e. “New With { Key .Country = “USA”, Key .State = “WA” }”). This modifier will do two things: one, it will make the field read-only (since keys have to be stable), and two, it will cause GetHashCode to be overridden and call the GetHashCode of the key field. You can have as many Key fields as you like, and the hash codes of all the keys will be combined. The LINQ query expressions will automatically use Key fields in any situation where a key is going to be generated (for example, Group By), but you will need to include the Key modifier if you are calling the LINQ APIs directly. Post-Orcas, we’d like to generalize this concept to all types and allow you to declare Key properties or fields, and do the same thing as with anonymous types. This will, we hope, simplify the work of making types that can be easily hashed.

IIF becomes If, and a true ternary operator

Many months ago, I discussed the fact that we were finally planning to come up with a true ternary conditional operator that would allow short-circuited conditional expressions. (Just as a quick recap: the current problem with the IIF function is that it evaluates all the arguments since it is just a regular method call. So “IIF(x Is Nothing, “Empty”, x.Name)” will throw an exception if x is Nothing, because we still evaluate x.Name.)

At the time, we were considering taking the IIF function and making it intrinsic. In the end, this looked like it would just be too big of a compatibility problem. There were lots and lots of subtleties around the return type and the short-circuiting behavior that were going to pose problems. So instead we simply reused an existing keyword and invented a whole new operator–the If operator. The If operator works just the way you’d expect it–it evaluates the first operand and if it is True, evaluates and returns the second operand. If it it’s False, then it evaluates the third operand and returns that. There is also a binary form of the If operator that takes a reference type or a nullable value type as its first operand. If the value is not Nothing, then the first operand is returned. If the value is Nothing, the second operand is returned. This is useful for doing a database coalesce operation, something like “If(x.Name, “<no name>”)”.

The result type of an If operation depends on the types of the two operands that might be returned from the operation. In general, we pick the wider of the two types. If the two types don’t convert to each other, then you get an error. (For example, if you did “If(<boolean>, <integer>, <long>)”, the result type would be long. If you did “If(<boolean>, <Button>, <string>)”, you’d get an error because there was no conversion between Button and string.)

One question people might have is, “why the parenthesis?” More than a few people have suggested an expression form of the If statement, something like “x = If y Is Nothing Then “<none>” Else y” or other variations that weren’t delimited by parenthesis. In the end, most everything that didn’t use parenthesis as delimiters just ended up looking funny when you put it in an If statement (“If z = If y Is Nothing Then “<none>” Else y Then…”) or funny when you strung a few of them together using AndAlso/OrElse. For what it’s worth…

The If operator won’t appear in Orcas until Beta2, unfortunately. So you’ll still have to wait a bit longer…

(And, as a final piece of trivia, why is the IIF function called “IIF?” It stands for “Immediate If“.)

Giving in…

Of course, some of the hardest parts of being a parent is giving up, giving in and admitting that you’re no longer the freewheeling couple that you once were. Bit by bit, kids chip away at any pretensions you might have of remaining young and/or cool. Thankfully, in my case that isn’t really giving up all that much–I mean, I was never really cool, so it’s not that much of a loss for me. My wife, on the other hand, was quite a bit cooler than me, and so she’s taking it a bit harder. Case in point–after much resistance, my wife admitted that a minivan would be a lot easier to get the kids in and out of than her little purple car. So she caved and now we have a shiny new red Toyota Sienna sitting out front. She hates to drive it, but already we’ve been putting it to good use…

On the plus side, instead of going directly through a dealership this time, friends recommended we use The Amazing Autowoman. Since Heidi is a buyer’s agent (i.e. works for you instead of the dealer), she really focuses on making the buying experience the most painless process possible. I’ve always hated the fact that when you go to buy a car you always end up with overpriced options that you don’t want because “that’s what’s available.” We went looking around the local dealerships to see if they had exactly what we wanted, and none of them did–so, of course, they pushed us to buy something with a different color or thousands more in options. When we called Heidi, we told her exactly what we wanted, she ordered it and we got it for an excellent price! (In fact, what we wanted was the base level of one of the models with NO options. When we got the car, we had to go and buy floor mats because that’s usually one of those options the dealership slips in there and charges you extra for. Definitely cheaper to go to Wal-mart!) If anyone is looking for a car, I defintely recommend checking her out!

Unforuntately, there wasn’t much she could do for my wife. At least we decided to keep her old little purple car so she can zip around when she’s just on her own and pretend…