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 >
