Andy Maggs asks:
Who thought it was cool to be able to create partial classes without indicating on the ‘primary’ class that it has other parts somewhere else. In C# you must use the partial keyword on all parts, so why not VB?
Since partial type cannot span projects (i.e. a type must be fully described inside of a project), we felt it was sufficient to only have to have at least one of the declarations “opt in” to partialness. Requiring every partial declaration to have to specify that it was partial seemed to be unnecessarily strict. For example, in the designer case such as a WinForm, it is really necessary to put “Partial” on the class declaration when the partial type that the designer spits isn’t even shown by default?
And, of course, there’s no reason that a developer can’t specify “Partial“ on all partial declarations if they so choose. You can even modify, say, the WinForms template to add it if you want.
In the end, this is one of those things I was talking about just last week, a real judgement call. There are more than a few people who have taken issue with this particular decision, feeling that the more explicit the better. (There have been even suggestions made to us that partial types should have to explicitly state which source file the other partial types reside.) I can see their point and don’t think their arguments are bad, we just don’t happen to agree on this…
Not to mention the benifit that this lets you make any generated code a partial class, like the proxy to a web service…
I thought you could extend a type declared partial, whether it is a part of your project or not!!! Then how does the My namespace extension work, if this is not possible??
My isn’t a type, it’s a namespace. Namespaces can be extended across assemblies.
Paul, I did not mean the main My namespace, but rather the lower hierarchy classes like the My.Computer etc. These are extended via partial classes, if my understanding is right.
Not sure I care one way or the other on this, but the decision seems to run counter to thinking you described as underlying the team’s decision to require explicit readonly property specifiers. Why is the fact that partial types can’t span projects sufficient for determining intent, but a property with a get and no set isn’t?
Eric: It’s not that we’re particularly against explicitness, just that it has to be balanced with practicality. In the discussion on ReadOnly/WriteOnly, I said it the explicitness was "nice" but not the main reason for doing it the way we did. (The main reason was that the alternatives were much more wordy.) I also think that more explicitness in this situation would be nice but that balanced against the practical results of that explicitness, it didn’t make the bar…
I only played with partial types a couple times with the PDC bits through XAML so I’m no expert, but won’t the lack of explicitness lead to confusion? I’ll install express soon and play with it. Unless the IDE gives you some type of hint that you are only looking at a partial class, it seems potentially problematic.
Since Partial is not required on the first class, can we view it as a way of extending classes?
Anand: I’m working off of memory, but the specific My stuff is constructed as a part of your project itself, which means that you can extend the My partial classes and not be going across assemblies. (This is why My doesn’t work in C# – their compiler doesn’t have special knowledge of My.)
The real downer in Whidbey’s support for partial types is not being able to navigate to the source of the rest of the partial type from within the IDE (at least for web projects). Doing a search for the class name in the newly-crippled class view yields the two files, but clicking the IDe-generated file gives me an error stating the file is "hidden". Why on earth would we decide to hide half a class’ implementation from the developer without giving him access to it? This violates two important principles IMO. 1. Developers should be able to see all code generated by the IDE 2. ASP.NET developers should be able to inherit their pages from a custom Page-derived class.
And bring back add override in the class view!!! Two steps forward and one step back….sigh
From the perspective of a VB source code analysis tool author, the lack of a requirement to apply the Partial keyword to all parts of a partial class causes me work, because whilst parsing a source file, I have no way of knowing whether a class has other parts defined in other source files until I have parsed all the source files in a project. If the partial keyword was required then it’s absence would mean that I could be assured that the complete class is defined in the single source file. Nothwithstanding this, however, it is quite simply inconsistent not to require explicitness here when VB.NET is so rigid everywhere else.
If C# always uses the partial keyword (and presumably went through the same level of debate) then why did the VB team approach it differently? I assume you guys talk to each other. I can’t see how Microsoft can justify a difference. While virtually everyone agrees that separation of designer code is desirable, it would appear that only the VB team feel the Partial keyword is optional. IMHO the VB team would do well to listen to feedback on syntax in order to avoid the same back-tracking in future that happened with areas such as properties which are now once again able to specify different accessibility levels for Get/Set. So far your private debates have got it wrong!
"Partial" is used to be called "Expands", which means "you can expands the definition of the class to this declaration" . In that case, we certainly don’t have to put "Expands" in each declarations. But for some reason I don’t know, this keyword was chaned to "Partial" like C#. Maybe this was the real reason<g>.
Christian: Not showing all generated code is something that both C# and VB have been doing since VS 2002, we’ve just extended it slightly in VB 2005. If you’ve got feedback on the way partial types are handled in the UI, do leave feedback at http://lab.msdn.microsoft.com/productfeedback/!
Andy: The optional use of Partial is consistent with things like the optional use of ByVal/ByRef, optional use of parenthesis, etc. Even in C#, the existence of the Partial modifier doesn’t mean there are other partial types in the project, just that there *might* be. So you still have to parse the rest of the project no matter what.
Fan: We changed Expands to Partial because the expands model (as nice as it was) didn’t work for all of the designers. Some designers needed to be able to emit code that would add to user code if it was there, but the expands model didn’t allow expanding a class that might or might not be there. Partial does that, so we changed it.
mustTryHarder: I think it’s worth expanding on your comments, so I’ll do that in a separate entry.
Paul, I normally agree with you but I must disagree on this point. I liken Partial to Overloads, kind of. While Overloads is optional if you don’t use it at all, it is required if you use it on one of your methods. I think the same should be true for Partial. If you span classes, it should be required on both. I think you’re going down a road right now that’s going to confuse a lot of people with potentiall "hidden code".
I really liked your book, btw.
Or what about adding the requirement for Option Explicit only?
Paul: Thanks I did just that. It’s not so much that I mind not seeing the generated code by default — as a matter of fact I think this cleans up the view a great deal. The kicker is not being able to see it *at all* without resorting to dirty tricks. And there’s just no good reason for removing the Add Override content menu item from Class View, but again it’s a bit off topic here and I chimed in at the Product Feedback center. 🙂
Paul: you seem to answer questions or points without fully understanding what has been said. I said that the ABSENCE of the Partial keyword could save me having to parse the entire project, not the EXISTENCE.
Chris: Option Explicit already has a fairly well-defined meaning, so I’d be loath to overload another meeting onto it.
Andy: You’re right — I totally misread your comment even though I read it two or three times to make sure I had it right. I completely apologize for that!
Pingback: Panopticon Central
I’m not even looking to view the code necessarily, but if I have some way to look at the events that I might decide to override, i’m not sure how to do that.
David: The dropdowns at the top of the editor will show you all the events that you can handle, regardless of where the event is defined.
"And bring back add override in the class view!!! Two steps forward and one step back….sigh" -quite right!
Pingback: Duncan Mackenzie .Net
Converting a project/solution from VS2003 to VS2005/2008 will not convert your Forms and UserControls source code to the new Designer+User style (using partial classes); they are left untouched in a single-file style.
That’s why I wrote DeCodEx, a simple and free tool to perform this conversion in a safe and quick way.
You could download it from here: http://coolsoft.altervista.org/DeCodEx
Please do not consider this as spam…, the tool is free!