Hi Jonathan, On Monday, 2007-08-06 16:45:13 -0400, Jonathan Pryor wrote:
> Unfortunately, the obvious way of doing this mapping would be to add
> constants to the FilterOperator enum in
> offapi/com/sun/star/sheet/FilterOperator.idl, and changing this file
> breaks my build because it breaks the ABI of a published enum. :-)
Yes, the (from a core implementor's view) always hated
enums-are-fixed-sets ABI ...
> What is the best way to solve this, so that we can persist the new
> FilterOperator values to the .ods file? I have one working (hackish)
> solution [2], but I doubt that this would be ideal.
Au contraire, it would forbid using the new values via API and break
already existing extensions written in Java (and maybe other languages)
that query the filter operator.
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.
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
constants FilterOperator2 {...};
struct TableFilterField2 : TableFilterField
{
com::sun::star::sheet::FilterOperator2 Operator2;
};
service DataPilotSourceDimension
{
...
[optional, property] sequence< com::sun::star::sheet::TableFilterField2
> Filter2;
};
interface XSheetFilterDescriptor2 : XSheetFilterDescriptor
{
sequence< com::sun::star::sheet::TableFilterField2 > getFilterFields2();
};
service SheetFilterDescriptor
{
...
[optional] interface com::sun::star::sheet::XSheetFilterDescriptor2;
};
and so on.. be sure you don't miss interfaces and services that make use
of XSheetFilterDescriptor and derived, there are a few. 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.
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 this [EMAIL PROTECTED] account, which I use
for
mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED]
Thanks.
pgpDaESCx07hM.pgp
Description: PGP signature
