Partial Methods. What The?

I alluded to this topic yesterday with my post "C# 3.0 Extension Methods? A Good Idea?". Today I want to discuss Partial Methods, another new feature of .NET 3.5. If you are unfamiliar with Partial methods, you can get a briefing here.

I think Microsoft has really gotten off track with this enhancement. The possible advantages seem so insignificant that I can't imagine why this was worth anyone's time. This is my #1 most loathed feature in all of .NET. The only feature I've seen talked about is a mechanism for lightweight event handling, or should I say pseudo-event handling?

We already have mechanisms for listening to events in .NET. If we want to perform operations in a BeforeUpdate() and AfterUpdate() manner we could listen to events which would fire named BeforeUpdate and AfterUpdate.

I understand the idea behind the "conditional method" aspect of the feature. But does it really kill us that much to use an if statement? Does one if statement which checks to see if any listeners are registered for an event kill the performance of the system? If this is your system, then I'm jealous. To get to the point where every if statement needs to be taken into consideration due to performance constraints seems like an intriguing problem, which many of us would love to work on. It just seems like there aren't many examples of this in the real world. We are ok with the statement which checks for event listeners. At least now our code is readable and we don't have to worry about not knowing what our code will output by just looking at our method's code.

This whole approach makes me think of JavaScript and the mechanism used for it's pseudo-event handling. It seems that with JavaScript we have taken the exact opposite approach to what we are seeing with partial methods. In JavaScript we used to rely (or maybe people still do) on a mechanism which is very similar to partial methods.

Haven't we all seen this:

<input id="btn" type="button" onclick="alert('button clicked');" />

or alternatively this:

document.getElementById('btn').onclick = function(e) { alert('button clicked'); };

The way this works is we assign a function to the already predefined declaration. Then the button object will call the defined method when the user clicks on the button. This is very similar to how partial methods are intended to be used. The developer (or code generator) will create a definition for the method. If you want some code of your own to run when an event takes place you simply provide the implementation of the previously defined method. There you have it, simple events in an old school JavaScript way.

But what have we learned with JavaScript? This isn't the best way to use events. What happens when we want to have multiple listeners? Using the above code whichever listener registers their method last will win, all earlier listeners will be discarded. We've been introduced to a new mechanism in JavaScript. For brevity I'll only cover the ASP.NET AJAX 1.0 approach. ASP.NET AJAX brought us the $addhandler() method which registers events on objects much like we are used to in .NET. Now we are able to have as many listeners as we want. We no longer worry about destroying prior listeners.

So if we have made these strides to move away from the "partial methods" type approach in JavaScript why is our new .NET library moving backwards? I really hope I never have to deal with partial methods in the code I work with.

What scares me most about partial methods is what happens when they get into the wrong hands. The potential for writing unreadable/unreliable code is astronomical. Lets all hope we are spared these experiences.

Am I off base here? What am I missing?

--John Chapman