[This post is part of a series, “wish-list for future versions of VB“]
IDEA: Allow you to override an event. This idea requires some explanation. Currently, both VB and C# allow you define events in interfaces, and implement them:
Event e As Action
Class DI : Implements I1
Public Event e() Implements I1.e
However, VB does not allow you to declare a MustInherit class with an event; and if a library (e.g. WPF) has created such a class in C#, then VB doesn’t let you inherit from that class:
MustInherit Class C2
MustOverride Event e As Action ‘ declaration disallowed in VB
Class D2 : Inherits C2
Public Overrides Event e() As Action ‘ overriding disallowed in VB
Finally, VB doesn’t let you declare an overridable event, or override it. C# does let you declare the overridable event but it behaves incorrectly when you try to actually override it…
Overridable Event e As Action ‘ declaration disallowed in VB
Class D3 : Inherits C3
Public Overrides Event As Action ‘ overriding disallowed in VB; buggy in C#
IDEA: We should allow users to inherit from MustInherit classes and override their MustOverride events.
This is a parity issue. Without this, VB users are simply unable to use classes such as System.Windows.Documents.Serialization.SerializationWriter (which is a MustInherit class with a MustOverride event). Note that this is entirely CLS-compliant. The only VB workaround is mock-type injection voodoo.
We could go further and allow declaration of MustInherit or Overridable events, and we could go even further and provide a correct consumption of “Overridable events”. But these seem like much less important.
Provisional evaluation from VB team: The most important parity issues for us are ones where VB users are shut out from libraries that are usable by C# developers. This is one such case. We therefore think this is an important problem to fix.