I think that shaver is saying that this is NOT CORRECT. The typelib will change if you add a new const to the idl.
Darin Fisher wrote: > right, one of the nice things about a flags-type attribute is that it is > easily expandable without breaking binary compatibility. and, so > provided the existing contract of the existing interface is not broken > (ie. provided the meaning of the existing flags doesn't change) then > everything should be okay. i agree with bbaetz: implementors must take > care to only check the bits they know/care about. flags-type attributes > give us some flexibility moving forward without paying the penalty of > extra QI's in our code. > > darin > > > > > Dan Mosedale wrote: > >> [EMAIL PROTECTED] (Christopher Blizzard) writes: >> >>> Doug Turner wrote: >>> >>> >>>> Suppose that the I have an interface that has a flags attribute >>>> (long). In this interface, I define the first few flags. Then we >>>> freeze the interface. A month later, I want to add a new flag. Can I? >>>> >>>> I am thinking that this change is okay even with a frozen interface >>>> - adding a new flags is okay - changing existing flags is >>>> unthinkable. thoughts? >>>> >>> That's the same as changing the interface. People who compile with >>> the new headers probably won't get the existing behaviour that they >>> expect with an older implementation and once an interface is frozen >>> it's frozen, right? "Interfaces never change." ( Am I repeating >>> myself? ) >>> >>> I think that you're taking advantage of the fact that you can >>> overload a flag since it happens to be a real number of some kind and >>> doing so breaking the contract that the interface promises. >>> >>> Besides, in this case, adding an nsIFoo2 interface isn't anywhere >>> near as painful as in the usual case since the implementation doesn't >>> need to change except to handle the new interface QI and the new >>> flag. The most expensive part is putting in the new .idl file. >>> >> >> In principle, I tend to agree with you, but it seems as though it's >> sort of overkill in places, such as >> xpcom/base/nsIProgrammingLanguage.idl. >> Even today, there's at least one language which has an XPCOM binding >> but is not listed there (Ruby). >> >> Dan >> >
