Hi Frank, On Thursday, 2009-06-18 10:40:15 +0200, Frank Schönheit wrote:
> In the concrete case, I think replacing the enum with an (extensible) > constant group is better than introducing the FilterOperator2, which > just adds clutter to the API. > > We would need to explicitly check this, but in my understanding the only > language binding where this is (compile-time) incompatible is C++. In > Java, it should be compile-time compatible, and perhaps even > runtime-compatible. All other language bindings should be completely > agnostic of such a change. If I understood correctly back years ago, changing an enum is not possible because in Java there is the Enum object that bails out if the value encountered during runtime doesn't match the set declared at compile time. Someone correct me if I'm wrong on this or there are details to add. > > Wouldn't it make sense to specify that constant groups are extensible > > per se, so that each code dealing with them must be able to handle > > unknown values? Perhaps with giving hints or specifying how unknown > > values of a particular group should be treated? > > Yes, would be a reasonable general guideline. Not sure we have a place > for such guidelines, though. Code implementing an API and dealing with constants or enums should always have some default case to handle unknown values. If there's a recommended treatment of unknown values in a specific constant group or API using it, that should of course be documented in the IDL. > > So constant groups could be changed at any time with good confidence, > > without considering this to be "incompatible". Without this explicit > > declaration adding constants to groups actually is incompatible, though > > we didn't AFAIK consider it to be so when we already added numerous > > constants to several groups. > > Does our watch dog bite when adding new constants to a *published* > group? No, it doesn't. Already did that. For obvious reasons just don't change the value of an already existing constant. While syntactically doesn't make it barf, it would create semantical confusion. Long story short: I don't introduce new enums anymore but use constants instead. This is ugly because you lose type safety of enums and maybe other benefits, but for the penalty of not being able to add new values it just isn't worth the hassle. Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the [email protected] account, which I use for mailing lists only and don't read from outside Sun. Use [email protected] Thanks.
pgpUyp2Lxcqhr.pgp
Description: PGP signature
