yes, i was referring to flags that are in effect optional. darin
Neil Hodgson wrote: > 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 > > > >
