C# 3.0 - Partial Methods
Posted
Friday, August 24, 2007 2:58 PM
by
lacya
Firstly, I must confess that up until now I have not really known about partial methods. Whenever I encountered any text on them I would assume they were mentioned in the context of versions of C# beyond the upcoming 3.0 release. So I thought I'd make up for it...
Partial methods are similar to the idea of partial classes (introduced with C# 2.0) where code is organized across different files, however they are worth closer scrutiny as to their uses and limitations.
A partial method is a method (with some restrictions) which is declared in one part of a partial class and is actually implemented in a separate partial class. Lets have a quick look at the syntax
internal partial class ProcessExecution
{
public void Execute()
{
OnExecuting();
Console.WriteLine("Execute...");
OnExecuted();
}
partial void OnExecuting();
partial void OnExecuted();
}
As you can see, I have defined two partial methods, namely:
- OnExecuting()
- OnExecuted()
In the following snippet, I have completed the implementation (in a separate code file)
internal partial class ProcessExecution
{
partial void OnExecuting()
{
Console.WriteLine("Executing...");
}
partial void OnExecuted()
{
Console.WriteLine("Executed.");
}
}
Now this will ultimately draw comparisons with Header and Code files in C++ and Interface and Implementation sections in Delphi, however this is not the case. This is due to the restrictions which the compiler places on partial methods, the most important of which are:
- Partial methods are implicitly private.
- Partial methods must only return void.
- Partial methods cannot accept out argument types.
- Partial methods don't always have a body.
So why the restrictions? To answer this lets actually have a look at the IL which is generated for two scenarios:
- The partial method is implemented.
- The partial method is not implemented.
If we look at the generated IL for the case where the partial method has an implementation, we can see that the methods have been added to our ProcessExecution class (below)
and the calls to those methods have been added to the Execute() method body (below).
Now lets compare it to where we declare the partial methods, but we do not provide an implementation of the methods.
As you can see from the image (above), the calls to the partial methods have been removed from the body of the Execute() method. Additionally, the actual methods have also not been compiled into the ProcessExecution class (below). Digging into the IL for a partial method which is not implemented, we can see the OnExecuting() and OnExecuted() methods are not present.
This is where the restrictions come in.
Should a partial method be allowed to return a result, the lack of implementation would have an effect on the target variable since we may expect a value to be assigned, but never is. This would be the same reason why out arguments are not allowed. By definition the argument needs to be assigned (even if it's to null) before it leaves the methods body.
The private accessibility restriction applies since there is no guarantee that the methods will be compiled to the assembly. As we've just seen, the implementation needs to be provided in order for it to be compiled and any of it's calls to be compiled. This protects any derived classes or calling class from calling a method which may or may not exist.
As mentioned, there maybe comparisons to C++ headers files and Delphi Interface / Implementation sections. However, there are differences in intent and usage:
-
Partial methods are implicitly private and cannot be accessed outside of that accessibility scope. C++ headers define types beyond these limitations and are used as a means to describe types and operations provided by the implementation.
-
Partial methods must return a void type and cannot have any out arguments. C++ headers file have no such restriction.
As for the use cases for partial methods, I recommend having a quick look at this post. The author gives us a explanation and where they could be utilized.