BT

Partial Methods: Do They Belong in C#?

by Jonathan Allen on Sep 06, 2007 |

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

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Code Generation & Architecture 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.

generation gap pattern... 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

Why always beating up on code-gen? 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!

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT