Christopher Blizzard wrote:
> Darin Fisher wrote:
>
>
>>
>> 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
>
>
> I think that it's wrong to say that bit fields are infinitely
> extensible, just because they happen to be bit fields and you can pass
> in whatever you want. The contract that we're talking about here
> isn't just a binary one as you elude to, it also defines what you can
> pass in and what the expected behaviour should be as a result of that
> call. I mean, why don't we just start using varargs for everything?
>
> If you change the interface you have to change the behaviour of both
> the consumer and implementor of that interface. If I've ever heard a
> definition of an interface change, that's it.
>
> --Chris
>
so there can't be reserved bits in an attribute's value? it seems to me
that there can, provided these rules are followed:
1) consumers must set all reserved bits to zero
2) implementors must ignore any reserved bits (they must not expect
these bits to be zero)
3) all bits, which were originally reserved, must be optional bits, with
zero being the default value ("default" meaning that the behavior of the
interface would match that of the original definition)
darin
