Enum types in IDL and in code

[Miklos Vajna]

Hi,

On Fri, Aug 07, 2015 at 04:52:36PM +0800, "Matthew J. Francis" <mjay.francis at gmail.com> wrote:
> How specifically should that be changed, though. In this case, merely
> changing the declared type to short would leave it such that its value
> is defined by the set of integer values of an enum, which is still
> annoying in terms of manipulation using PyUNO and peculiar in terms of
> the IDL.

If the documentation says that this is a short, exact possible values
are defined here and there, I don't see that worse than the current
situation. :-)

> An equivalent constant group could be added, although that would be not
> ideal in a different way - the original enum definition couldn't be
> removed, as it may still be used for instance by existing Python code
> to blindly assign values to the property.

I think we add equivalent constant groups only in case the
enumeration would be extended (but isn't to avoid incompatibility), e.g.
text::WritingMode vs text::WritingMode2.

> Any advance then on the idea of:
> - Making the declared type short

I would do this.

> - Adding a constant group for it
> - Deprecating the enum

I would only these if there will be a new item for the enumration in the
future.

> I note that for this particular case, css::report::XReportControlFormat
> declares a ParaAdjust attribute which is actually a short - the
> documentation would need changing there to reference the new constant
> group, but not the definition.

This is a problem for Writer paragraphs' ParaAdjust property, too:

text::Paragraph refers to style::ParagraphProperties, which says
ParaAdjust is a style::ParagraphAdjust, which is an enum.

In reality, sw/source/core/unocore/unomap.cxx says UNO_NAME_PARA_ADJUST
is a sal_Int16.

In case all other ParaAdjust implementations (I'm sure at least editeng
has one) also deal with a sal_Int16 in fact, then just changing
'[property] com::sun::star::style::ParagraphAdjust ParaAdjust;' to
'[property] short ParaAdjust;' in the IDL file (and using a comment to
still refer to the enumeration informally) would make sense, I think.
Even if the in-build check complains that this is nominally an
incompatible change.

Regards,

Miklos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20150807/43ca95c8/attachment.sig>