Testing UNO API service properties

[Jens Carl]

On 03/27/2018 01:29 AM, Stephan Bergmann wrote:
> In a rather unfortunate and confusing way, 
> offapi/com/sun/star/sheet/XFunctionDescriptions.idl mentions the 
> css.sheet.FunctionDescription old-style (see below) service description 
> as a source of documentation for that sequence<css.beans.PropertyValue>. 
>   Documenting such a sequence<css.beans.PropertyValue> with an old-style 
> service description (that lists only properties, no interfaces nor 
> super-services) is a misuse of the UNOIDL concepts.  But a misuse that 
> goes unpunished, because it's all merely documentation.
> 
> So as a user you can guess from the documentation that the 
> sequence<css.beans.PropertyValue> returned by getById will have five 
> elements, "Id" of UNO type LONG, "Category" of UNO type LONG, etc.  And 
> such a sequence is a "pure" value detached from the object from which it 
> was obtained via getById, so changing its elements wouldn't have any 
> effect on the original object.  That's probably the reason why the 
> properties of that misused css.sheet.FunctionDescription are marked as 
> readonly.  Even if it is technically nonsense, it expresses the moral 
> equivalent of there being no way to change the original object's values 
> that are obtained via getById.

So coming back to my original question: So the intended behaviour is 
they're read-only and meant to "display" only some information?

Going forward the I see a couple options:
1. Only test the get part and ignore the set part, because there is no 
value to it.
2. Drop these tests (don't convert them from Java to C++).

I'm for option one, but maybe there are other options?

Thanks for the explanation. It helped me to understand how things are.