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". If some
UNOIDL construct documents requirements for a type (e.g., used as an
interface method parameter type), then any code using that construct
must adhere to those requirements.
While it can be easy for a UNO language binding to automatically "fix
things up" when e.g. an UNOIDL interface method has a parameter of type
sequence<string> and the (Python) caller code passes in a Python object
that would normally be mapped to a UNOIDL sequence<any>, there can be no
magic fixup when the parameter is of type any and only some additional
protocol (unknown to the language binding; e.g., some documentation of
the UNOIDL method) dictates the requirement that a certain call of that
method must e.g. actually pass in a sequence<string> wrapped in that any.
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.
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
