Mike Shaver wrote:
> Christopher Blizzard 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.
>>
>>
>> Binary compatibility isn't the only thing we have to worry about
>> here, guys. There's this contract thing.
>
>
> ...which is why I argued, so long ago, that we needed to sort out
> things like startup, shutdown, and per-instance/contract threadsafety
> stuff before we declared things "frozen".
>
> I was alone on that, though, so I've stopped pushing.
>
> Mike
>
what is an interface contract exactly? in the case of a bit field
attribute, is it wrong to say that only specific bits are currently
defined and that other bits are reserved for future use? the contract,
in this case, is well defined for all consumers of the interface. this
is a very common way of making an interface ever-so-slightly extensible,
and IMO it definitely seems like it would be useful in helping us freeze
several mozilla interfaces. are we worried about changes to the .xpt
files? would modifying .xpt files somehow cause runtime problems?
darin
