Re: [sc-dev] Saving Filter Options (i#35579)

[Stephan Bergmann]

Michael Meeks wrote:

On Thu, 2007-08-09 at 23:35 -0400, Kohei Yoshida wrote:

or else some way to introduce a process to allow modification of the
existing, published interfaces.


So - the thing that is most interesting about this is that this should
not be impossible to achieve, at least for C++.

Surely, we can construct a dynamic proxy if we discover that the size
of the interface queried for = sizeof that implemented, that stubs, or
maps the extra vtable slots as appropriate ? That might allow appending
methods to existing interfaces ?

Java  co. would require more thought than C++ I guess, they'd be a
spanner in the works :-) has this been considered at all ?


FYI: http://udk.openoffice.org/servlets/ReadMsg?list=devmsgNo=3894

-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sc-dev] Saving Filter Options (i#35579)

[Stephan Bergmann]

Kohei Yoshida wrote:

On Tue, 2007-08-07 at 13:35 +0200, Eike Rathke wrote:

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.


To put this into perspective:  The restriction to not add to published 
UNO enums is not due to any UNO languag binding limitations, but is a 
necessity for building robust software.  In general, it is unknown what 
the existing users of a published UNO entity are, and a design choice of 
UNO is that a user of a published entity shall continue to work even 
after (valid) changes have been made to that entity.  For an enum, 
adding new values would break existing consumers of that enum, that 
would not know how to handle the new values.  Hence, extending a 
published enum is not considered a valid change.


-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sc-dev] Saving Filter Options (i#35579)

[Eike Rathke]

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