Regarding partial method implementation

You should clearly understand that partial methods are nothing but syntactic sugar, they don't affect any additional functionality, ever; they are designed only to improve code readability and make some steps on development process a bit more convenient. Only convenience, nothing about functionality. And absolutely none of those powerful feature Krunal tried to attribute in Solution 1.

Please see: http://en.wikipedia.org/wiki/Syntactic_sugar[^].

The possibility to have some non-implemented method is a somewhat delicate moment, so I'll have to illustrate it on some examples. In brief: this is not something to be taken too seriously. :-)

Let's start from the most extreme case of non-implemented method: let's declare it and even call, without implementation. The resulting behavior is something unusual. Let's see:

public partial class PartialDemo {
    partial void Test(); //important: the method is private!
    internal PartialDemo() {
        Test(); // simply does nothing, can work during runtime
    } //PartialDemo
} //class PartialDemo

public partial class PartialDemo {
    // no implementation of void Test() yet
} //class PartialDemo

Pay special attention for my code comments, they explains pretty much everything.

This is what happens: the compiler statically detects that Test has no implementation. It compiles the code into IL in the following way: as if the method was never declared and called. Every piece of code behaves as if Test was never mentioned.

Now, the question is: why is is done so? For some, it would be convenient, but I personally don't need this feature much. This is done for one simple purpose: it is implied that the implementation will be written later, but without it, the code would still compile and even executed. I, for example, have a habit to re-compile code excessively often, because — why not? I write a line and re-compile. I write declaration without implementation — it compiles. So, for me, this is a bit of convenience, but I would easily leave without it. I would also suggest that adding this feature (not partial methods, but the ability to keep some methods not implemented) was decided under the influence of C/C++ culture, where there is a similar feature, albeit not really safe.

One thing you should understand: the code written above makes no sense. You never should write it without implementation for any thinkable functionality. You can consider this almost as a "compilable comment" saying: "implement it later". So, if you never add implementation later, it would defeat the purpose of using the feature in first place.

Now, all this feature (having no implementation) will work only of the partial non-implemented method is private. If it is public or protected (and the method is not abstract, of course), the compilation would make no sense at all. Public assumes that you can call the method from other assembly. But other assembly is compiled separately; it cannot "know" that in one case the the method exist and in other case it is not. This is a real call; and a call is a call. It won't compile even with internal. This design decision is not so critically important as with public or protected, but is reasonable. Let's see:

public partial class PartialDemo {
    internal partial void First(); // WON'T COMPILE
    protected partial void Second(); // WON'T COMPILE
    public partial void Third(); // WON'T COMPILE
} //class PartialDemo

public partial class PartialDemo {
} //class PartialDemo

Each of those non-private methods will compile as soon as you add its implementation.

So, this feature cannot solve as any plug-in facility. Plug-ins can be based on reflection.

It also does not affect the possibility to auto-generate code. Remember, even before partial types were introduced, the auto-generated code was pretty much the same, only in one single file. That was very unreadable. Besides, it provoked used to update with the code the same file where the auto-generated code is. It could easily create a lot of mess. With partial types, it's a lot safer; in case of developer's mistakes, it's much easier to find ends. I personally often add my own partial declarations to types, in separate files, including auto-generated ones.

[EDIT]

However, Microsoft suggests and interesting way of using auto-generated code, the way fully based on the mechanism I described above. It is described in the MSDN article reference in Solution 3, second link. Credit to pwasswer for this link. Please see it.

Again, the idea is the same: isolation of the auto-generated code and the developer's code. In this approach, the auto-generated code uses unimplemented partial methods. In a separate file, in the other part of the same class, the user can add implementation to such methods. With recompilation, the non-existent calls to such methods are replaced with actual calls. This way, the user can inject the calls into auto-generated code by adding code in a separate part, and, hence, possibly in a separate file. You can think of it as of compile-time way of overriding which is not based on dynamic dispatch like in OOP, but is based on early binding. It does not have the OOP power, not at all, but it does not have that (tiny) overhead of the call of the virtual method. Hm…

It's important to understand that, from the stand point of functionality, this mechanism is 100% equivalent to just editing of the auto-generated code, adding some code to it and recompiling. But auto-generated code is not the real source code, in practice, it should not be edited. So, from the standpoint of project maintenance, it makes a big difference: isolation of auto-generated and developer's code.

So, I would speculate that this technique could be the major reason for .NET team to introduce partial methods without implementation. I am not sure I like it, because to me, it looks like adding an ad hoc feature for the sake of such a secondary goal as the techniques based on auto-generated code.

[END EDIT]


It just improves readability of code and ease up maintenance, if used reasonably. Pure syntactic sugar, no more.

—SA