Darin Fisher: > 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.
Contracts should work both forwards and backwards in time. When a piece of code using the new flag value is run against an old implementation of the interface that does not understand the new flag value then the result should remain reasonable. If it is a QOS option such as [attempt to flush to disk after each write] or similar than it can be ignored. If it represents a feature option such as [return 48 bit deep bitmap] and the interface is defined to return failure for unsupported flag values then that is also fine. What would not be reasonable is defining a new flag that changes the behaviour deeply (such as turning a read into a write) on an interface where such a possibility is not documented and so implementations may just ignore the flag. What is important here is whether the object model is to be robust for the "new client against old implementation" case. COM is defined to be so. A less static object model could be defined where implementations are known to be newer than client's rquirements through version checking. Since many of the services consumed by XPCOM clients are in Mozilla, such clients may be able to just require a particular minimum version of Mozilla. Neil
