Hi,
But I think the most striking advantage a typeunsafe over a typesafe
language has, is that you need to write less source code to do the
same thing. If the language binding would be designed with an
queryInterface, the advantage would vanish hurting you with nearly
every line of uno code you write, so I would implement it again this way.
This depends very much how the queryInterface is implemented: whether
the programmer needs to explicitly carry it out, or whether the runtime
support could do that "under the covers".
your approach is not so different than the other one implemented in the
scripting components.
However, encouraging this as 'default' writing is problematic when ooRex
can also implement uno objects ( can it ?).
In pyuno, you can implement uno objects simply by implementing a python
class with the relevant methods and signaling via the getTypes() call,
which interfaces you implement. When local uno code calls local uno
objects, these calls are direct python calls (no uno runtime inbetween).
So currently, my scripting components workaround will not work with
local objects, because there is nobody, that translate
com_sun_star_foo_XFoo_doSomething() to doSomething() (or the other way
round). This is problematic, when you have code that shall work with
both local and bridged objects. You should have a similar problem. There
are 2 approaches to solve this, one is to add another runtime method for
the caller
uno.invoke( objectReference, interfaceType, arguemnts ... )
(which makes the calling code very ugly ) or to force every uno object
implementation to implement both qualified or non qualified methods or
in your case proxy-interface objects named XFoo which delegate to the
objects methods (which makes it ugly to implement an object no matter
how much helper code you introduce).
So I will probably go for the uno.invoke() solution in the hope, that
this situation is very seldom needed ...
Bye,
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
