Bradley Baetz wrote:
> On 9 Oct 2001 02:40:42 GMT, Doug Turner <[EMAIL PROTECTED]> wrote:
> >Suppose that the I have an interface that has a flags attribute (long).
> > In this interface, I define the first few flags. Then we freeze the
> >interface. A month later, I want to add a new flag. Can I?
> >
> >I am thinking that this change is okay even with a frozen interface -
> >adding a new flags is okay - changing existing flags is unthinkable.
>
> I think that as long as the behaviour of the original class remains the
> same, this is OK. Its reasonable to require a class which wants the new
> functionality these flags give to be updated, though.
>
> However, I don't think that we want "extended" flags, where, for example,
> a flag set on a loadgroup would imply different semantics wrt
> onstop/onstart. That has the potential to get very confusing ("Class X
> will do foo, unless flag x is set, but flag y is not set until after
> calling the bar method....")
Agreed, existing flag bit meaning should not change without a new IID. The
cases you sketch here are just the same as if one changed method semantics,
which (although the compiler won't check for incompatible semantic
changes) are just as verboten for a frozen interface as method type signature
changes.
> Implementers _must_ handle flags they don't understand - ie if the only
> current values are 0 and 1, a client must handle 3 exactly like 1. I can't
> imagine this being a problem, but I guess it should be documented.
An old implementation should not break if it finds flag bits set that were
not defined when it was written.
/be
