On Thu, 11 Oct 2001 14:20:34 -0400, Christopher Blizzard <[EMAIL PROTECTED]> wrote: >Bradley Baetz wrote: > >> I think that a generic "all flags are extendable" rule is wrong. However, >> not in all cases. The nsIProgrammingLanguage example given is one example. > > >For something that needs to be extensible like that they really should >have used a string to pass back by name. The fact that they are enums >means that you have to break the interface every time that you want to >add another language to the list. I think that as an example, >nsIProgrammingLanguage goes to show my point more than yours. :)
Well, possibly there could have been a better design choice. However, in what way does this break binary or source compatability, or the contract? The other option, of an nsIPRogrammingLanguage2, which just defines an extra constant, doesn't seem to have a point. >> >> Another one is my changes to bug 89500, which made the "does this protocol >> support proxying" a flag variable. For various reasons (like the fact that >> irc/mailnews don't really use that interface to create channels), an >> nsIProxyableProtocolHandler wasn't a solution. If you ignore the fact that >> I changed the name of the flags variable, then adding two extra bits was >> not an issue. Existing protocols didn't have to be changed, Those that >> wanted to support proxying did have to change to get the new >> functionality. >> >> That still keeps the contract to existing classes. >> > >Existing protocols didn't have to be changed but clients of the >interface that expect ( possibly ) old modules that say that they >support that interface would get errors or possibly crashes because they >were using an old module with a flag that the old module wouldn't have >known about. That's breaking the contract and it's wrong. In what way? This assumes that we do document that people should ignore. Old users of these classes wouldn't know how to get the additional benefit, but anything they were doing would continue to work. > >Either freeze an interface or don't. It's up to you. But don't change >a bitfield on an interface and say that it's still backwards compatible >because it isn't since the contract has been changed, even if it's in a >way that's binary compatible. The contract has been extended, not violated. If we agree that action A does E, that doesn't preclude action B doing something else. The only way this could be noticed is someone compiling an object using the new constants against an older version of the interface - this would fail. However, it would also fail if we'd chosen to define a new interface instead. > >--Chris > Bradley
