Christian notes some differences between the way C# and VB implement interfaces, prompting Peter to ask “Was it accidental or intentional?” The answer is: it was intentional. The exact thought process that lead to the current design is somewhat misty in my memory because it was so long ago, but here's kinds of how it went:
VB6 supported implicit event handling and interface implementation very similar to the way that C# does implicit interface implementation. You stated that you implement an interface and then you used a “magic name” to implement a method in the interface. When we were designing VB 2002, though, we wanted to allow people to handle multiple controls' events with a single handler. The magic name design for event handling would have effectively prevented that, because there was no reasonable “magic” name that could mean “hook me up to x.Click and y.Click.” (C# obviously doesn't have this problem since they don't support declarative event handling.) So we decided to drop magic naming for event handlers in favor of an explicit Handles clause that allowed multiple events to be handled.
Once we'd taken that step, we decided we liked the new explicitness of event handling and decided that it would work for interface implementation as well. It meant that we could get rid of clunky VB6-style magic names (i.e. “Sub IDisposable_Dispose(...)”) entirely and also meant that a single class member could implement multiple interface members, although so far I don't know of many places where that comes in super-handy (since most interfaces are, by nature, discrete from one another). Also, because it didn't rely on magic names, there was no chance that you might “accidentally” implement an interface member without realizing it.
Previous Topic
