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.
I think the flexibility the original designers of UNO had in mind was more along the lines of having a UNO object dynamically decide whether it wants to indeed offer some of the functionality it implements, or using aggregation to dynamically let a master object offer all the functionality of several aggregated slave objects. In retrospect, using UnoRuntime.queryInterface instead of plain Java language casts was definitely a bad choice.
-Stephan
[...]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
