Joerg Budischewski wrote:
Hi,
I have no idea how pyuno does it. But note that this problem was
there from the beginning, and has nothing to do with the addition of
multiple-inheritance interfaces. There are, for example, already
cases where one UNO object implements both XComponent and
XEventBroadcaster, and I have no idea how pyuno handles a call to
addEventListener on such an object. However, since this problem is
there from the beginning, I assume that the designers of pyuno took
care of that in an appropriate manner.
On second thought, all "dynamic" UNO language bindings (where
statically you can call any method of any UNO interface that a given
UNO object supports on that object, without mentioning the specific
interface, and where dynamically the runtime dispatches the method
call to the correct interface) are broken: A method call (with
whatever actual syntax)
someUnoObj#foo()
will work as long as the UNO object referenced by someUnoObj only
implements one interface that defines method foo, but will fail as
soon as that object also implements another such interface.
there is a workaround implemented in the scripting components such a
way, that you can invoke e.g.
a.com_sun_star_lang_XTypeProvider_getTypes()
instead of
a.getTypes()
which works (or should work) for pyuno, starbasic, ole, etc.
My point was that you do not know in advance which calls to decorate in
this way---so, to write robust code, you would have to decorate all
calls (except on objects you implement yourself). And, as the language
bindings do not encourage you to do this, you typically end up with
fragile code. Not every code needs to be robust, of course; however,
users of a language binding have to be aware of this problem, so that
they can judge for themselves.
As long as people stick to the naming conventions (no _ in method
names), this is fine.
I am not sure whether this works also for implementing objects in pyuno,
(but I guess not). And it can not prevent the problem that when you have
code, that should run with either a bridged and a uno object
instantiated in your current pyuno env. Then above code will not work
(no glue code inbetween, direct calls).
However I think such a problem is not very common.
Adding the need for querying explicitly for interfaces would uglify
bindings a lot, so this is no option from my point of view.
Bye,
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
