Jörg Budischewski wrote:
Hi,
As Stephan pointed out such means do exist in Basic and they are
described in our DevGuide. I don't know if PyUNO has means too so we
must ask people knowing the binding. AFAIK Jörg Budischewski is reading
the udk list so perhaps we should move the discussion there.
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.
I would not say so (for one example, think of type inference in ML; for
another example, implementing ad-hoc--polymorphic functions probably is
more "lightweight" in C++ than in Scheme). However, I see what you mean.
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.
The irony here is that UNO (and hopefully the OOo API) needs less
queryInterface than it did in the past. That means that a sufficiently
lightweight (in terms of what you need to type into the keyboard)
query-interface--mechanism in a dynamically typed language need not
spoil the party (i.e., you would need it seldom, and where you need it,
it would not be too ugly). Which shows that the UNO-ease-of-use
features are not only relevant for statically typed languages, as I
previously assumed.
As you need to QA your 3rd party basic or pyuno software eitherway with
every new office version (at least to ensure that new implementation
bugs don't break your functionality) and there is a workaround when you
encounter such an incompatibility, this is not really a problem.
At least in prinicple, there can be cases where only in certain corner
cases or in certain deployment scenarios you come across an object that
implements a conflicting set of interfaces.
-Stephan
Bye,
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
