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!)