[EMAIL PROTECTED] wrote:
> Christian Biesinger wrote: > >> David Einstein wrote: >> >>> Is there a way of dicovering all of the classes that implement an >>> XPCOM interface? > > Well, yes. > What about at runtime? > The application that I am looking at is the spell checker. It would be > nice if multiple spell checking engines could coexist and the user could > choose the one most appropriate. This is usually done by each concrete class adding itself to a category (with nsICategoryManager) or by registering with a parameterized ContractIDs - by composing a ContractID string based on a set of values. It really depends on usage, but generally if one wants to enumerate members of a group of objects, then Categories are used. I think the important thing to distinguish here is the difference between implementing an interface (i.e. holding to the contract described by the interface) and actually being a member of a group which provides a set of services. i.e. the syntax and semantics of an interface don't necessarily mean that it is a provider of a specific set of services. It is a subtle difference in the spell-checker case, but here's a more generic example: We use nsIObserver to provide generic generic object-to-object observation/notification mechanism. The contract (the interface) says that one should implement the interface to be notified about events. The 3 parameters to Observe() specify information about the event. One use of nsIObserver is to notify objects that certain preference values have changed. However, that does not mean that all objects which implement nsIObserver are interested or should be called when a preference value changes. The set of interested objects is a subset of the set of objects which implement nsIObserver. Alec > Pangloss would want these objects to not have to be hardwired into mozilla. > Deinst >
