PartialClasses are an upcoming (2004? 2005? 2006?) mechanism in C# (CeeSharp) and other DotNet languages. See http://www.developer.com/net/net/article.php/2232061

Why does MicrosoftAvalon at once promote composition (http://microsoft.sitestream.com/PDC2003/CLI/CLI301_files/Botto_files/CLI301_Bogdan.ppt (PPT)) *and* simultaneously base XAML (http://notgartner.com/posts/151.aspx) on partial classes, a new language construct for weaving a single class from multiple sources?

Why is composition not good enough? Or if not, why is inheritance not the next best thing? I have yet to see a rationale for introducing another mechanism for organizing object-oriented code.

Partial classes are different from open classes in Ruby, at least in the sense that all Ruby classes are open, but only so declared classes are partial in dotnet. Also in Ruby anything can be redefined, whereas, I think, in dotnet, each partial class definition can add something new to the class but not redefine what is in another definition.

Partial classes seem kind of like defining a C++ class using #include to include the *.cpp definitions themselves. But it has been a long time since I used C++ and I have never used partial classes in dotnet. (Few have since it is not in production yet.)

''While C++ allows the implementation of a class to be scattered about however you like (simply omit the implementation of a C++ member function from the class definition), the definition of the class itself can only be in one place.  C++ classes are not "open" in this sense.  (C++ namespaces, on the other hand, are open)''

(Question originated here http://patricklogan.blogspot.com/2004_01_25_patricklogan_archive.html#107472433955305867)

Isn't this like the Smalltalk concept of extending classes? For example, you can add custom methods to String or Integer in Smalltalk (these specific examples might not work in Dotnet) [Steve Wart 2004/05/09]

''If I recall correctly, the reason for including partial classes is that generated code (e.g. GUI-code) can be separated in another file that you don't need to see when editing code. This way you can also be sure that the builder won't mess with your code because it will only touch the other file.''

It was already done this way (ASP.NET 1.0), but the generated form inherited from the code behind. This may be a marginal improvement, but the general scheme suffers the usual defeats of CodeGeneration, like obscure syntax errors in code you didn't write. -- JesseMillikan

''Many products have bugs initially. Surely CodeGeneration is not so difficult that the bugs can't be detected and fixed.'' 

It isn't a matter of ''bugs'', in this case. Rather, it is that the top layer of the system, the layer that is generated ''on top'' of your own code, is undocumented, brittle and inflexible. (This goes at least for 1.0.) I say this from a few years of experience, but I think the latent bad properties can be imagined. It isn't that it ''doesn't'' work or can't be made to work, just that it's a poor solution that is difficult to use for non-trivial things. -- JesseMillikan

A syntax error in the generated code would imply a bug (or at least a lack of validation) in the generator. If the generated code is merely of poor quality, the problem lies in the design of the generator. There's not much excuse for either of these to be typical of CodeGeneration. --

Er, syntax error is not the right term, I guess. A common example: You add a user control to a page, add it as a member to the code behind page, and then get an error compiling the generated code because the protection level of the control in the code behind is not 'protected'. (Happens often enough; user controls do not by default add the member to the code behind page.) There are more complicated and less obvious problems, though. 

Anyway, I would expect partial pages to fix at least ''that'' problem, since members can no longer be hidden from the generated code.--JesseMillikan ''(8/31/07 - I was wrong, this does cause problems even with partial classes.)''