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 leas
Michael Meeks wrote:
Hi Stephan,
On Wed, 2007-08-08 at 09:46 +0200, Stephan Bergmann wrote:
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.
A necessity
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
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
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
