On Mar 30, 2005, at 11:58, Stephan Bergmann wrote:
Henri Sivonen wrote:I think the UNO-Java bridge necessarily leads to less beautiful code. If the Basic runtime can work without queryInterface, why doesn't the Java bridge make the proxy objects implement the exported interfaces right away?
Java is statically typed, while Basic is dynamically typed.
Sure.
However, the returned type of XSomething.getSomeObject in UNOIDL might be XSomeInterface1, and only additional documentation in the UNOIDL file explains that the returned object will in fact also implement XSomeInterface2, XSomeInterface3, etc., and optionally also XSomeOtherInterface1, ...
This explains why Java UNO needs some sort of dynamic cast here (UnoRuntime.queryInterface or Java's casting mechanism;
But that does not explain why the proxy objects don't implement all the exported UNO interfaces as Java interfaces so that one could use Java-level casting and instanceof.
the choice of the more verbose UnoRuntime.queryInterface over Java's casting mechanism is probably due to a perceived gain in flexibility).
The only flexibilities I can come up with is disambiguating methods with the same signature in different interfaces, but allowing that would break Basic, and objects adding features after they have been instantiated, but surely that doesn't happen, either.
Thank you. This bit was what I needed. Are the supported property set keys documented somewhere?
Yes, in the UNOIDL documentation of the relevant UNO service.
Thanks. Somehow I managed to not understand how to set the properties when I was browsing the docs and then to forget that I had seen the list in the API docs.
-- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
