Now that C# 2.0 is almost here, I'd like to know about features that were left out from this release and planned for the future.
We are primarily focused on getting Whidbey polished and out the door right now, so there isn't a lot of thought about features beyond Whidbey right now. Even when we do get into that mode, I probably won't be talking about it.
One of the reasons that we don't like to talk about things when their in the investigative phase is that they are very preliminary. If I said, for example, that we were thinking about adding parallelizing capabilities to C#, then that would be likely to set up an expectation. It might turn out that we weren't able to do that, perhaps because there wasn't a good way to design it, we didn't have time to build it, one of the teams that we were collaborating with changed their focus or schedule, or a multitude of other possible reasons.
Traditionally, we've been fairly binary on this - we don't talk about things until they're already implemented and tested, even if it's fairly sure that we're doing them. We are trying to figure out how to be a little more open in that area.
Why can't we have .Add and .Remove aswell as += and -= operations after all its just a collection, I was rather supprised that this method wasn't actually available for adding event handlers.
One of our design goals is not to have more than one way of doing something (in contrast to Perl's tmtowtdi). If there are two different ways of doing something, developers need to learn both ways and understand that they are equivalent. That makes their job more complex without any real benefit.
Another area that this shows up is on delegates. Since C# has a special syntax for invoking delegates, we don't let you call Invoke() directly.
I've been tracking topics I wanted to cover in various methods (excel spreadsheets, Post-It (tm) notes, “post-it compatible” notes, writing on my hand, and graffiti in my office).
It's been hard to keep all of those straight, so I'd like to centralize them in a blog post. If you have a question that you'd like me to answer, please add a comment to this post with your question.
I'll put a link on the top-level web page of my blog, so that you can easily get to it. I'll try to put some of my own ideas there as well.
Partial classes can be pretty cool because of the opportunities it gives in separating machine or designer generated code from user code. It does present a few issues, however.
One that we've been talking about recently is a scenario where you have some machine generated code that can function by itself, but sometimes your user wants to extend it. And, to extend it, the user needs to have some code run as part of the constructor.
That presents a problem. If we want the user to be able to use the class by itself, it needs to have a constructor in the generated code (assuming, of course, that the generated code needs a user-written constructor, which is true the majority of the time), but that prevents the user from writing a constructor themselves.
We talked about this from a design perspective, and explored some ways in which you could write “partial methods” - for want of a better term - in your partial classes. It is possible, but in all the schemes we came up with, you end up with weird ordering constraints (“I want the user constructor code to be inserted after the first 2 lines in the constructor but before the remaining 10 lines...”)
So, basically, those schemes were all untenable.
How can you do this? Well, the best way is to provide some designer support to add a call to a user method at the appropriate place.
A customer wrote me today to ask, “Why can't I do arithmetic on byte types?” For example, if you write:
byte a = 0x01;byte b = ~a;
The compiler will complain on the second line that you can't convert an int to a byte. This happens because there are no operations defined for any types smaller than 4-byte types. The question is, “Why?”
Back in the old days, when a 5 MB disk drive was the size of a washing machine and memory was measured in the KB (ie when I went to college), memory and disk storage was very precious, and you did your best to conserve it. But times have changed. If you look at most programs these days, you'll find that they do the vast majority of their operations on 4-byte operands. And, in fact, x86 processors are very good at these operations.
But to get fast at those operations, many processors are slower at accessing smaller-than-4-byte operands, so if you use them you will have a program that's slower to execute.
Given that, the C# and CLR designers decided to only define arithmetic operations on 4-byte and 8-byte operand sizes. It does mean that you have to have some casts when using smaller types, but it's more indicative of what's going on at the chip level.
So, that's what's going on here.