Re: Enum types in IDL and in code

On 05/08/2015 21:13, Stephan Bergmann wrote:
> Old-style services that only list a bunch of properties, like
> css.style.ParagraphProperties, are mainly glorified documentation,
> telling a human that a UNO object documented to support that service is
> supposed to support an XProperty of the given name and type.
>
> I am not aware that PyUNO nor the underlying UNO reflection/invocation
> facility actually make use of this information (but may well be wrong).
>
> So when you say that "this is confusing for PyUNO," do you mean it is
> causing trouble somewhere in the innards of PyUNO (i.e., PyUNO or the
> underlying reflection/invocation is making use of the old-style
> properties-only service information after all), or do you mean it is
> causing trouble at the level of a Python program written assuming that
> reading some ParaAdjust value would provide some Enum value while in
> fact it provies an integer value (i.e., it is the author of the Python
> program who gets fooled by the inaccurate ParagraphProperties.idl file)?

Mainly the latter confusion. The problem the user I was discussing this
with had was that when trying to develop using such an interface you
have no idea what the value you receive from it is unless you can find
it in the IDL, and when you do so it suggests that it should have been
an actual enum to begin with.

As mentioned, there's currently no property of the Python Enum class or
instance that tells you what its integer value(s) might be. Ideally
these would be pointless to know in this context, though I could add a
way to get them - just not sure how much improvement in usability this
would be.

Alternatively or as well, it might be possible to transform such
"almost but not quite enums" into proper Enum instances by paying
attention to the interface definition rather than only the yielded
values. As you rightly point out, nothing currently does. However, this
would seem quite inelegant unless there are at least several such cases
- I'd be interested to know if there are any more.
(Making the PyUNO Enum comparable to integers would avoid this being a
change in behaviour to existing code)

Regards
Matthew Francis