Bradley Baetz wrote: > On 11 Oct 2001 13:39:33 GMT, Christopher Blizzard <[EMAIL PROTECTED]> wrote: > > >>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? >> >> > > 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. :) > > 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. 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. --Chris -- ------------ Christopher Blizzard http://people.redhat.com/blizzard/ Mozilla.org - we're on a mission from God. Still. ------------
