In principle we have the necessary mechanisms in Basic and PyUNO (see
previous post by Jörg). However, since the existing mechanims are
"heavy" and ugly, they are not used consistently in practice. That
means that much of the code that is written in those language
bindings is fragile. Rony is right in that another approach to the
design of those language bindings might have made it easier for users
to create robust code.
The only option to solve this 'unfragile' is to introduce a mandatory
queryInterface() call however it might look like.
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".
E.g., in the ooRexx support for UNO/OOo the connection-routine looks like:
------------- cut here -------------
::routine UNO.connect public
parse arg unoURL -- retrieve the argument, if any
xContext=.UNO~Bootstrap~bootstrap -- get an initialized local UNO
runtime environment
if unoURL="" then -- no unoURL given, use default (local installation)
return xContext -- return the context object (which can be used to get the
service manager)
-- use the received unoURL to establish a connection to the remote object
uur=
xContext~getServiceManager~createInstanceWithContext("com.sun.star.bridge.UnoUrlResolver",
xContext)
remoteObject = uur~XUnoUrlResolver ~resolve(unoURL) -- get the connection
return remoteObject
------------- cut here -------------
Looking at the code (the tilde is the message operator, i.e. left of it
is the receiving object, right of it the name of the message), there is
no queryInterface() at all. However, wherever the name of an interface
is used as a message name (like at the end of the code snippet, the
message "XUnoUrlResolver"), the "under the covers" support will carry
out the queryInterface().
Here another code-example which creates an empty swriter document and
adds text to it:
------------- cut here -------------
-- Example 01: open an empty swriter-file and write "Hello World!"
-- Retrieve the Desktop object, we need its XComponentLoader interface to load
a new document
oDesktop = UNO.createDesktop() -- get the OOo Desktop service object
xComponentLoader = oDesktop~XDesktop~XComponentLoader -- get componentLoader
-- interface
/* open the blank *.sxw - file */
url = "private:factory/swriter"
writerComponent = xComponentLoader~loadComponentFromURL(url, "_blank", 0,
.UNO~noProps)
/* write a string into the writer component */
writerComponent~XTextDocument~getText~setString("Hello World!")
::requires UNO.cls -- get UNO support
------------- cut here -------------
Again, the interface names (starting with an "X") are used as normal
message names, and the "under the covers" ooRexx support for UNO will
take care of the queryInterface() calls to be carried out behind the
curtain, so denominating the interfaces to work with becomes an
unobstrusive task (that's also the reason why I have been contemplating
not to implement the OOo Basic resp. Python behaviour, where one can
forgo the denomination of the desired interface altogether, which also
will leave the coder a little bit orientless as from where the methods
come from).
Probably, most people are able to understand the above code and can
easily realize from which interfaces which methods get employed.
---rony
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
