If you go and look at the bug, the point as not putting the contract id's in the idl. The point was: should we drop in a dozen header files which all contain a single contract id, classname, and cid. I think that many of these files could have been reduce. For example, why create seperate files for core necko 'things'. The point is purely aesthetic. **However, I can imagine a nsCCoreNeckoStuff.h which includes the set of files which have been created for bug 124465.
Doug Turner Darin Fisher wrote: > well said... i agree completely. > > darin > > > > Rick Potts wrote: > >> The idea behind putting contract-ids in separate header files is very >> simple. contract-ids and the documentation regarding a component's >> usage/behavior apply to a component implementation where as IDL files >> describe interfaces -- NOT components !!! >> >> It is quite possible for a component to implement many interfaces >> (the nsWebBrowser is a good example). This begs the question 'which >> IDL file should the conbtract-id live in?' Further, documentation >> describing a component (yes at some point we need this kind of >> documentation) needs a distinct place to live. Not in the random IDL >> files of the interfaces which the component happens to implement. >> >> I think that alot of this confusion stems from the fact that we do >> NOT have much component-level documentation... so these header files >> look kinda bare ;-) But hopefully, at some point in the future these >> header files will provide valuable documentation describing how to >> use a particular component (in addition to it's contract ID and a >> convenient list of interface headers that automatically get included)... >> >> I feel very strongly that component-level documentation does *not* >> belong in abstract interface files... For example, i can't imagine >> why we would ever want to sprinkle documentation relating to a >> particular nsWebBrowser implementation in ALL of the interface files >> that the browser component either implements or 'accesses via >> doGetInterface()'... And this is just *one* component. If we did >> this for ALL of our components, our interface IDL files would become >> piles of useless crap... >> >> -- rick >> >> >> Alec Flett wrote: >> >>> I've got one word for you on "nsC*", and that word is 'Travis' :) >>> >>> I actually think its a decent convention, but I also think that >>> putting contractIDs in IDL files are ok (i.e. according to some >>> folks, that would make me a heathen) and prefer the >>> contractids-in-idl because its one less header to include for the >>> cases where there is a default implementation. >>> >>> That said, I think this is (unfortunately) something that needs >>> further discussion in a public forum... >>> >>> Alec >>> >>> >>> >>> Judson Valeski wrote: >>> >>>> Darin's got some freezing questions at the bottom of this bug. >>>> Because he's not actually freezing a class ID, contract ids and >>>> interfaces AFAICT, it's not clear to me where the "nsC*" convention >>>> came from and the comments at the bottom of >>>> http://www.mozilla.org/projects/embedding/HowToFreeze.html are >>>> throwing me off. >>>> >>>> Some help? >>>> >>>> Jud >>>> >>>> http://bugzilla.mozilla.org/show_bug.cgi?id=124465 >>>> >>> >>> >>> >> >> > >
