Partial Methods: Do They Belong in C#?

Posted by Jonathan Allen on Sep 06, 2007

Community

.NET

Topics

Programming

Tags

Code Generation ,

C#

One of the more controversial additions to C# is partial methods. A partial method is usually defined in a partial class file and is optionally implemented in the regular class file. If the partial method is not implemented, the compiler strips out all mention of it.

Partial methods are heavily restricted. They must be private, cannot return a value, and cannot have out parameters. These restrictions are necessary because any calls to a partial method that was not implemented are simply ignored. This in turn means it cannot be used as a definite assignment to a variable. Visual Basic also has partial methods and though VB does not require definite assignments for variables, it has the same restrictions.

With all these restrictions, one has to ask, "What are they good for?" Well basically, they are only used by code generators for a sort of lightweight event handling. As Alexander Jung explains

The usual (probably the only relevant) use case for partial methods is light weight event handling in combination with code generation. Say, you parse a database or an XML file and generate data classes. Tens of classes, hundreds of properties, all fairly generic, boilerplate stuff. And also fairly common is the need to interfere with this method for validation or that property setter to update another one. So instead of manipulating the generated code or having hundreds of events and thousands of method calls during runtime (of which in most cases only a tiny fraction will actually do something) partial methods kick in. They are easier to declare and use than events (pay for what you need) and if not used they simply vanish (pay as you go).

This performance boost is not free. Because of the restriction that partial methods must be private, Alexander has uncovered these flaws.

The con: If you like metadata driven applications (and already struggled with ASP.NET databinding because there is no way to attach meta data)… well, prepare for some further loss of information. If you need some event for any property setter (for tracing or tracking), if you need any kind of dynamic behaviour (e.g. to attach some kind of generic rules engine), … let’s just hope the developer of the code generator anticipated that use case (or prepare for some work). You have a clean layer separation and the entities should know nothing about the UI? Well, put your code right into the data class will spoil that. But hey, you might use partial methods to implement real events. Manually.

Other people are likewise concerned about partial methods in C#. Most of these concerns come from the use of code designers. Stefan Wenig writes

First, because I'm not a big fan of designers. I'm quite worried they'll soon enough be sending us down the same road that COM-based development went in its last years, with hundreds of designers and wizards that generated ATL and MCF code nobody ever wanted to read. The Ruby crowd will be laughing their asses off with a few lines of source where we'll be stuck with designers and generated files and complicated build processes. (Compare that to COM/C++ vs. Java in the late 90s!) Wasn't C# about code-based developer productivity in the first place (vs. VB's designer-driven RAD road map)? You should be the last to care about the whims of the designer-based, enterprise-library-minded, software-factory-code-generator-happy folk. Resist!

Ayende Rahien is even less kind,

Let us corrupt C# for code generators: The horror story of partial methods

1. Back to top

   Code Generation & Architecture

   Sep 6, 2007 12:41 PM by Stefan Tilkov

   We often apply code generation in our projects, following a light-weight MDE/MDA approach ... one of my personal rules has always been that the fact that you're generating code should not affect your architecture - if it does, something is wrong. Letting code generation affect your programming language seems even worse.

   Reply

2. Back to top

   generation gap pattern...

   Sep 7, 2007 2:02 PM by andrew mcveigh

   For code generation where I may need to add manual bits later, I've always used the generation gap pattern. Generated code goes in the base class, manual code goes in the subclass.
   
   www.research.ibm.com/designpatterns/pubs/gg.html
   
   A bit of a nuisance, but works well.
   
   Having said that, partial classes aseem useful to me for breaking a single class up into multiple files.
   
   Andrew

   Reply

3. Back to top

   Why always beating up on code-gen?

   Sep 9, 2007 9:02 AM by Mat Hobbs

   Code-gen is the perennial whipping boy but will always be with us, for as long as modularity and performance are still important.
   
   Is it trends from academia vs. the real-world? Academia has the voice but the real-world makes the money!

   Reply

• Older >