为什么C＃没有像VB那样的Handles子句？

Question

In VB, we have the Handles clause, that allows add a Handler to an event of a control without putting it into the xaml file (directly into the VB file).

xaml:

<Button x:Name="myButton" />

VB:

Private Sub Button_Click() Handles myButton.Click

End Sub

One good thing that can be done using this is the possibility to use the Visual Studio dropdowns to add events automatically without the need to go to the xaml file and change it. Read this question (and the answer) to better understand what I'm talking about:

Visual studio 2010 showing available events from code behind

The answer of that question doesn't specify why C# does not have this feature inside Visual Studio, but it's clear for me: C# does not have this feature because it uses the Handles clause to add the event on CodeBehind.

I know that we can make use of the += and add the event manually on the constructor, below InitializeComponent (that is almost the same thing), but VB also have the AddHandler that can add events on the constructor (and in other places), and it's not automatic and less reliable (for me) than the Handles clause.

My question is:

Why it's never implemented? It's non-reliable? Non-secure? There's any workaround?

Answer 1

It was never implemented because no one at Microsoft thought it was useful enough to justify the effort. The exact reasons why can only be answered by someone on the C# team. And while it's true that C# and VB have made an effort to synchronize their features, that doesn't mean they're going to retroactively introduce all VB-specific features in C# or vice versa. (Note that the Handles clause has always existed in VB.NET)

However, one can speculate based on VB's history as a language why it might have been introduced. Namely, that's how VB events pre-NET always worked, so VB developers would probably be used to it.

In traditional VB, events were wired up to objects by name. If you have a Form and you define a subroutine named Form_Load , it will run as your form's Load event. This tradition carried over into ASP, and still lingers as the AutoEventWireup configuration option. VB developers were used to the language knowing what method to run for which events without having to "explain it" to the compiler.

In .NET languages, events are just a particular kind of property with a special type (a delegate type) that have to be assigned like any other property. In order to allow VB developers to transition easily into VB.NET, though, you would ideally give them an easy way to do so without having to learn about events and delegates and handlers (at least not immediately). The Handles keyword accomplishes this -- you just tack on Handles Load onto your Form_Load sub and it becomes an event handler.

C#, on the other hand, has no legacy behavior that it needed to maintain. The target audience for C# consisted of people from many languages, most of which had no built-in concept of events and certainly did not have the auto-wireup behavior of VB. So there was no need to introduce this behavior into the language, but instead, new C# developers would just learn the "right way" of doing things from the start.

With the introduction of WPF and MVVM view/model separation and the push for minimal code-behind, a handles keyword becomes a bit more attractive, but it still seems to go against the general principles of how C# handles events. I suspect it would take a very, very strong argument to convince the C# team that it was worth implementing.