After introducing it with
much fanfare, I've been very negligent in actually
answering anything submitted to
Ask a Language Designer. So let me start to make
amends. The first questions I want to address were narrowly asked but touch on a
broader question. Both Muhammad Zahalqa and Kevin Westhead ask why VB doesn't
have a
'using'
statement like C# has and when/if we will have one in the future.
The general question of "Why doesn't VB have feature x?" is,
as you can imagine, one that keeps coming
up over time. It's gotten even more common since C# came on to
the scene, since VB and C# are much closer to each other than, say, VB and C++
are. So I thought I'd spend a little time talking in general about why some
features that exist in other languages don't make it into a particular release
of VB. And, in the process, I'll address the question of the 'using' statement.
When a feature doesn't make it into VB, it's typically because of one of the
following reasons:
- It's a bad feature. I'm throwing this in here because it does
happen every once in a while that we get a request for a feature that some
other language has that we think is just a bad idea. There isn't anything
that I can think of off the top of my head that's fallen into this category, but it does happen.
- It's not a good match for VB. There are some features that we
think just don't make sense for our customers and the kinds of things that
they do. It's not that we think that nobody would ever use the
feature, just that it's very unlikely that most of our users would
need or use the feature. The prime example of this is the unsafe code
feature in C#. Although there are situations in which people use unsafe
code, they tend to be pretty limited and very advanced. In general, we believe that
even very advanced programmers can happily exist in the .NET environment
without ever needing unsafe code and that it tends to mainly be programmers coming
to C# from C and C++ that find the feature useful. (Our
experience since shipping VS 2002 and VS 2003 has so far validated these beliefs.)
- It's not a good cost/benefit tradeoff. Some features are good
ideas, but the benefit gained by having the feature doesn't seem to justify
the time it would take to design, specify, implement, test, document and
ship the feature when compared against other features we want to do. To pick a prosaic example, the C# command-line compiler
csc.exe
has a feature where it will read in a "default" response file that contains
references to all of the .NET Framework DLLs. This means you don't have to
explicitly "/r" DLLs like System.Windows.Forms.DLL when compiling an
application on the command line. It's a nice idea and handy on the command line, but in the
past the overhead of implementing the feature in vbc.exe was judged to be
higher than its benefits. So it didn't make it into the
product for VS 2002 or VS 2003. The danger, of course, is that little features like this can end up
being constantly cut from release after release because
they're not big enough to be "must have" features, but not small enough to
escape the ax. (You'll just have to give it a try in Whidbey to see whether
it made it in this time or not...)
- We ran out of time. This has got to be the most painful situation
for the product team, because it's something we desperately wanted to
get done but for one reason or another, we just didn't have time. So instead
we have to sit back and suffer the slings and arrows of outrageous fortune for not
having the feature, contenting ourselves only with the knowledge that
next time will be different. A prime example of this is operator
overloading. We really wanted it for VS 2002/2003 but it was too big to fit into
the schedule. We'll definitely be doing it in Whidbey.
So what about the 'using' statement? One of
the major struggles of the VS 2002 product cycle was trying to figure out how to
deal with the transition from reference counting (i.e. the COM model) to garbage
collection (i.e. the .NET model). We spent a lot of time trying to see if we
could make reference counting coexist with garbage collection in a way that: a)
was reasonable and b) was comprehensible by someone less than a rocket scientist.
While we were doing this, we deferred making any decisions on garbage collection
related features like the 'using' statement. After banging our heads against the proverbial
wall for what seemed like forever, we came to the very difficult conclusion that we couldn't
reconcile the two and that full-on garbage collection was the way to go. The
problem was, we didn't reach this dead end until late in the product cycle,
which meant that there wasn't enough to time left to properly deal with a feature
like 'using'. Which, let me just say, really, really, really sucked. So
the painful decision was made to ship without the feature and, yes, we said to
ourselves next time will be different.
Is this time different? This is another one of those
things that you'll have to try out in Whidbey to see... (wink, wink)