Re: CID vs. ContractID

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