Req28: Override events


[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:


Interface I1


    Event e As Action


End Interface


 


Class DI : Implements I1


    Public Event e() Implements I1.e


End Class


 


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


End Class


 


Class D2 : Inherits C2


    Public Overrides Event e() As Action  ‘ overriding disallowed in VB


End Class


 


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…


Class C3


    Overridable Event e As Action  ‘ declaration disallowed in VB


End Class


 


Class D3 : Inherits C3


    Public Overrides Event As Action  ‘ overriding disallowed in VB; buggy in C#


End Class


 


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.


 

Comments (2)

  1. Héctor says:

    Never realized about this, but after reading the post, I think this *must* be added.

  2. SomeGuy says:

    I have identified a workaround of sorts for the overridable event case – just split the interface for the base class!

    Create a base class, and implement an interface without events needed in a derived class.

    Then, create an interface WITH required events that inherits from the base class interface.

    Finally, create your derived class, inherit from your base class, and implement the combined interface.

    This enforces events AND gives you a workable base class. Functionaly, the combined interface is no different.