WARNING: This is a speculative post. Caveat emptor.
This one is a little more speculative than the others, but it’s something that we’d like to get some feedback on. One complaint that we get from time to time has to do with interface implementation. A lot of people like the fact that there’s a nice explicit interface implementation syntax in VB, but sometimes it starts to feel, well, a little verbose. Even if you let the IDE create all the interface implementations for you, there’s still a lot of extra characters with all those “Implements IFoo.Bar”s, especially when the implementing method is the same name as the interface method.
One idea we’ve been kicking around is relaxing our rules to allow for implicit interface implementation. Today, when we’re checking interface implementation for some interface I1 what we do is:
- Check to see if any base classes implement any of the members of I1. If so, we mark those methods as implemented.
- Check to see if the current class implements any of the members of I1. If so, we mark those methods as implemented. If the current class implements a method that a base class implemented, the current class replaces that implementation.
- If all of the methods of I1 are not implemented, we give an error.
What we would do is slightly modify the rules to:
- Check to see if any base classes implement any of the members of I1. If so, we mark those methods as implemented.
- Check to see if the current class implements any of the members of I1. If so, we mark those methods as implemented. If the current class implements a method that a base class implemented, the current class replaces that implementation.
- If there are any methods of I1 that are not implemented, we check to see if there is a method with the same name and signature in the current class, and if there is, then that method implements the interface method.
- If all of the methods of I1 are not implemented, we give an error.
What this would mean is that you could do something like this:
Class C1
Implements IComparable(Of Integer)
Public Function CompareTo(ByVal other As Integer) As Integer
End Function
End Class
And not get any errors. There are a couple of things to note here if you’re familiar with C#, though. First, unlike in C#, if you declare a method in a derived class that has the same name as an interface method that is declared in a base class, you will still have to explicitly implement the interface method if you want the derived class method to take over. For example:
Class Derived
Inherits Base
Implements IComparable(Of Integer)
' Will not take over IComparable(Of Integer).CompareTo since Base already implements it!
Public Function CompareTo(ByVal other As Integer) As Integer
End Function
End Class
One could argue whether the derived class should or shouldn’t take over the implementation, but the bottom line is that if we allowed this we would be opening a potentially serious backwards compatibility problem. The above code could be written today (assuming Base implements IComparable(Of Integer)), and CompareTo will not take over the implementation of the interface. If recompiling your application in some future version of VB switched the implementation, this could introduce a very subtle and possibly very bad bug into your program. So it’s really a non-starter.
The other difference from C# is that we won’t search base classes for implicit interface implementations. For example, the following code would still give you an error:
Class Base
Public Function CompareTo(ByVal other As Integer) As Integer
End Function
End Class
Class Derived
Inherits Base
' Error: IComparable(Of Integer).CompareTo is not implemented!
Implements IComparable(Of Integer)
End Class
This can also be debated, but in the end we tend to err on the side of being more conservative—since Base didn’t implement IComparable(Of Integer) itself, it seems odd to pick it up when implementing the interface, as we have no way of knowing for sure that it’s really appropriate. There are also other highly technical issues relating to the mechanics of interface implementation that would make this situation complicated, especially if Base was in another assembly that we had no control over.
So the question is: would people find this useful? Annoying?
Total Members
