Footnotes
1. Easy is a relative term: without COM, some sorts of programming are simply not possible and thus the term easy is utterly empty. [Back]
2. The term interface is used in a very similar sense in the Component Object Request Broker Architecture (CORBA) design of the Object Management Group. In both cases the idea of an interface is a signature of functions and, implicitly, capabilities, entirely abstracted from the implementation. The major difference between COM and CORBA at this high level is that CORBA objects have one and only one interface while COM objects can have many interfaces simultaneously. DCE RPC (from OSF) uses the term interface in a similar manner. [Back]
3. Indeed, in principle the intrinsic method dispatch overhead of COM is in fact less than the intrinsic overhead of C++ multiple inheritance method invocations. In a multiple inheritance situation, C++ must on every method invocation adjust the this pointer to be as appropriate for the actual method which is to be executed. In an COM object which supports multiple interfaces, which is directly analogous to the multiple inheritance situation, one must of course also do a similar sort of adjustment, and this is done in the QueryInterface method. However, when using a given interface on the object, one can invoke QueryInterface once and use the returned pointer many times. Thus, the cost of the QueryInterface operation can be amortized over all the subsequent usage, resulting in less overall dispatch overhead. Be aware, however, that this distinction is completely academic. In almost all real word situations, both dispatch mechanisms provide more than adequate performance. [Back]
4. There can be subtle differences in the flow-of-control between calling in-process and out-of-process objects. In particular, an out-of-process object call may result in a call-back prior to the completion of the original call. COM provides standard mechanisms to deal with call-backs and reentrancy; even on single-threaded operating systems. Without such standards, true interoperability between out-of-process objects (of which cross-network objects is just a typical case) is impossible. [Back]
5. Although class and type can often be used interchangeably, in COM a type is the total signature of an object, which is the union of the interfaces that the object supports. Class is a particular implementation of a type, and can include certain unique implementation-specific attributes such as product name, icon, etc. For example, the chart type (identified by a GUID by whomever first defines that particular combination of interfaces) might be supported by Lotus™ 1-2-3 for Windows and Microsoft Excel for the Apple Macintosh, each of which are separate classes. Normally, types are polymorphic; any consumer of the services provided by interfaces making up the type can use any class that implements the type. [Back]
6. As an illustration of how unique GUIDs are consider that one could generate 10 million GUIDs a second until the year 5770 AD and each one would be unique. [Back]
7. See, for example, Richard Helm (Senior Researcher, IBM Thomas J. Watson Research Center), Ensuring Semantic Integrity of Reusable Objects (Panel), OOPSLA '92 Conference Proceedings, p.300; John Lamping (Xerox PARC), Typing the Specialization Interface, OOPSLA '93 Conference Proceedings, p.201. [Back]
8. Readers interested in this issue should examine the connectable object architecture described in Chapter 11. Connectable objects enable an event model that provides a standard, powerful convention for a COM object to signal to any interested client that is about to do something, that is doing something, and that it is finished doing something. The model also allows clients to cancel the event outright or to cancel it in favor of an overriding event supplied by the client. This event model coupled with a few additional conventions could provide COM with all the traditional features of implementation inheritance and more without the traditional risks. For an interesting discussion of the problems of traditional implementation inheritance as well as a description of how an inheritance system might be provide robust type-safety, see Hauck, Inheritance Modeled with Explicit Bindings: An Approach to Typed Inheritance, OOPSLA '93 Conference Proceedings, p.231. [Back]
9. Not only are there situations where there is a need for designs optimized for cross network efficiency, but there are also cases where in-process efficiency is more important. Just as COM provides mechanisms whereby the remote case can be optimized (custom marshaling) it also allows for the design of interfaces that are optimized for the in-process case. [Back]
10. Monikers are COM's way of providing support for what other object systems, such as. CORBA, call persistent interfaces. [Back]