Christian Biesinger wrote: > So... is there really an "official policy"? Is it written down in some > document, describing when to put Contract IDs in .idls, and when not? > If not, wouldn't it be a good idea to create one?
cid should *never* be in a IDL file. IDL's define interfaces not implementation. ContractID strings may be documentation in a IDL. I think that the reason behind people yelping about putting contract id's in the IDL is that the common place for them is wrapped for C++. IDL is suppose to be language neutral. Yes, this would be a good think to put up on the website. Send me a draft! :-) The super-reviwers should all know about this rule and it has been part of our API freezing process. Yes, there are tons of places we break this rule. > The discussion continued on CIDs versus Contract IDs, I'll summarize it: > jfrancis was of the opinion that CID and Contract ID have pretty much > the same purpose - both identify an implementation of a well-known > interface. > > hwaara and I, on the other hand, were of the opinion that a CID > identifies a specific class, while a Contract ID identifies, well, > adherance to a given Contract. (possibly implemented by multiple > classes, each one with a different CID). > > So the question: > Who is right? Should CIDs still be used in new code? > And shouldn't there be a document somewhere on mozilla.org describing this? Hwaara and you are correct. Contract IDs do not specify a particular class implementation, but rather define a functional set of APIs. CIDs should be used within a grouping of strongly coupled modules (or better yet, rethink the use of COM in this area). They should also be used in places where a specify implementation of a IID is required. ContractID are nice in that they will always give you the current version of a IID implemention. However, they can be more expensive to uses (119937). Doug Turner
