On Tue, 2007-08-07 at 13:35 +0200, Eike Rathke wrote: > The usual approach to extend such an API is to introduce a second new > enum range, or if adding to the values is planned for the future using > a constant is more appropriate, since extending constants is no problem.
IMO, We probably should assume that this will be extended again sometime in the future. So, that would eliminate use of enums for this. > To use the new enum/constant all structs using the old FilterOperator > enum need a derived version, optional properties been added, and > additional interfaces need to be implemented for all these data types, > and offered either as an optional interface at the already existing > service, or via inheritance. For example [snip] > and so on.. be sure you don't miss interfaces and services that make use > of XSheetFilterDescriptor and derived, there are a few. OTOH, we should incorporate such change into the change I was making for the multi-selection filter extension. (Remember we had discussion on this awhile back?[1]) Since I'm making a huge change in that same area, adding this change to my set of changes will not be a huge pain, since my pain is already big enough to begin with :-). > And yes, > having to carry out this work is extremely nasty just to add some values > to an enum. And yes, this is the reason why I refrain from using enums > in new interfaces if there is only the slightest chance that another > value would had to be supported in future. Which makes enums pretty much > useless, IMHO. Yes, very unfortunate. I wonder if the UNO enums could have been translated into constants just for Java binding, instead of using Java's (obviously very limited) enum constructs... But I guess we can't really back out of it since it's already set and done. Kohei [1] http://sc.openoffice.org/servlets/ReadMsg?list=dev&msgNo=2388 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
