Hello Stephan,
thank you for weighing in!
On 16/05/2019 09:20, Stephan Bergmann wrote:
On 15/05/2019 15:27, Thomas Viehmann wrote:
but that isn't really what this is about, it's about what sequence
types are expected when an any is passed.
My intuition would be that the more specific type is better when
applicable, but I would value your input whether such a change would
be considered an improvement.
There is no "better" or "worse" here, just "right" or "wrong".
In terms of calling the UNO method, I agree. However, I would venture
"better" binding API would be one that offers fewer surprises which is
where I don't see this as great.
That is, the PyUno language binding had to make a choice how to e.g. map
a Python tuple of strings into a UNOIDL any value. It may be debatable
whether the current choice (apparently mapping to a sequence<any>
instead of, say, a sequence<string>) is useful. Be aware that revising
that choice is an incompatible change. It may make writing certain
Python code more intuitive, but at the same time it may break existing
code.
Yeah, well, to me it looks like this was potentially done by accident
because reducing the sequence conversion to item conversion is very
attractive to the one implementing this API but the resulting API is
maybe less attractive to the one using it.
To move this forward or abandon:
0. I had half hoped that someone would step in and say that needing to
pass a sequence of Any wrapped in a single Any to an interface is a rare
thing.
1. If we were to form the opinion that not that many extension will be
impacted, would this be changeable or do we prefer to not apply breaking
changes at any rate?
2. If 1. is yes, would investigating github projects featuring "import
uno" and checking whether and how they use "Any" interfaces be an OKish
assessment method?
3. Independent of 1 and 2, maybe it would be a good idea to accept
constructed Any values when the UNOIDL signature demands Any to avoid
having to go through uno.invoke. I think having to spell Any("[]String",
...) instead of ... is still much better than going through invoke. Also
it might be nice to annotate known cases of needing to do this for
Python in the API docs.
Best regards
Thomas
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
