Frans points out some C# and VB language constructs that he thinks are superfluous. In the interests of a deeper understanding of the language, here’s the thinking behind the three VB ones:
- ReadOnly and WriteOnly property specifiers. When we were coming up with the new property syntax in VS 2002, we discussed this issue in great detail. Some people felt that the extra bit of explicitness was nice, but what really got it into the language was interfaces and abstract properties. In both of those cases, you don’t actually specify an implementation for the Get and the Set, but you need to specify whether you expect them to be there or not. One way of attacking the problem is the way C# does it, where you just specify an empty Get and/or Set. But with VB’s line orientation, this ended up with a lot of wasted screen real estate (and it just looked weird in VB to have a Get with no End Get). ReadOnly and WriteOnly were the main alternative, and we liked them much better. We did talk about whether they should be optional for properties that do have a Get and/or a Set, but we felt that it was better to have consistency about when we did and did not require them.
- WithEvents with form controls. The truth is that WithEvents fields hide a whole lot of magic. (If you’re interested in exactly what, you should check out what the VB language specification has to say about WithEvents.) The most important thing that happens, though, is that a WithEvents field is always wrapped in a property. This is not a minor thing for two reasons. First, it changes the behavior of the field when it’s passed by reference – real fields can be passed true byref, while properties have to be passed copy-in/copy-out. (I just recently wrote the part of my language book on this, maybe I’ll post some of that in here at some point.) But more importantly, accessing a property has slightly more overhead than accessing a field, so there’s a slight penalty to declaring a field WithEvents. Given those two things, we decided we wanted to retain the VB6 convention of specifying WithEvents so that it wasn’t something that was done lightly or accidentally. The problem now, though, is that designers such as the Winforms and Webforms designers just put "WithEvents" on things willy-nilly so that they can add handlers later, resulting in the opposite effect of what was intended. This unintended consequence is something we’re trying to work through in Whidbey.
- Overloads when Overrides. This is really just a bug in the language design. (Yes, we do have those.) Frans’s logic is completely correct on this point, and it’s something we were already looking at fixing. But for now, you’re stuck with it…
Feel free to throw other things you think are superfluous my way through comments or through Ask a Language Designer. (Yes, I am going to be answering some questions from there soon. I promise!)
didnt quite get why you felt withevents is useless.. how else do you access events in your calling appliaction?