The "ultimate question" raised earlier had a loaded catchphrase: "Given a way to identify an object of a class…" Corresponding to the four answers to the question itself, there are four basic ways to uniquely identify a class:
The key to all of these identifications is uniqueness. By design, the name of an API function is unique within the system and so is unique among all components and applications. Because interfaces are unique, so are the member functions they contain. Those functions that create new objects uniquely identify the class of object they create. Objects that are created within a client for the express purpose of communicating with another instance of an object—for example, an event sink—need be unique only within that client because there is no other way to get at the object. In such cases, a compiler will enforce a unique internal name.
The fourth method is a bit trickier: the case in which custom components are uniquely identified within an entire system and, in the future, across an entire network. The primary issue here is that distributed environments have potentially millions of components, objects, and interfaces that need unique identification. Using human-readable names for finding and binding to all of these elements (used for system APIs and internal class names) will certainly result in collision. The result of name-based identification will inevitably be the accidental connection of two or more software components that were not designed to interact with each other, and this will result in an error or a crash, even though the components and the system had no bugs and worked as designed.
The problem seems worse when you consider that many components and interfaces are developed at different times by different people in different places. How can you possibly guarantee uniqueness when there is no communication among vendors?