Objects are for communication. A key to good design is to choose good names. This Longhorn class should be renamed now:
System.Xml.XPathDocument2 to set an example.
What does the name
XPathDocument2 tell me, the reader? Well, it basically tells me there is an
XPathDocument (or maybe an
XPathDocument1 and perhaps an
It also suggest that the
2 class was developed some time *after* the first one. It might tell me not to use the first one. I don't know. The
2 is noise that wants to be information.
A better name would tell me that
XPathDocument2 can be disconnected from the source, not tied to a DOM, and used for read/write, and provides change notifications. The numeral
2 cannot tell me that. Neither does it tell me that the original DOM-bound
XPathDocument still may be a good choice in some scenarios.
I don't know exactly what the better name is, but it is out there in the conversations that led to its creation, and (unfortunately) in the conversations that will take place among its consumers. Maybe
ReadWriteXPathDocument is a good choice, but only real conversations (as opposed to the ones going on in my head right now) will tell.
This post has nothing to do with XML and XPath or Longhorn. It has everything to do with why objects are important and will remain useful for their original purpose: code organization. Good names are a key to good organization.
Well, this post *does* have something to do with Longhorn... the developers at Microsoft are creating now the language many developers will use for probably a decade. Please take the time to provide meaningful names. Two years before the release date is *not* the time to affix numerals to the end of classes for relatives that provide alternate functionality!