shiny uno version, Desktop IDL

Bjoern Michaelsen bjoern.michaelsen at canonical.com
Thu Jun 14 04:14:51 PDT 2012


On Thu, Jun 14, 2012 at 11:40:20AM +0100, Michael Meeks wrote:
> 	The problem is - if you use a Java or C# binding that requires types,
> and can provide intelligent auto-completion in the code (at least until
> we hit an 'any' or 'queryInterface') - then using this overly-generic:
> 
> 	any doIt([in] any);
> 
> 	style interface for everything not only robs you of documentation and
> auto-completion, but also means that you have to go lookup the types
> carefully to make sure you don't shove an any into a string when it is
> really an int (or whatever) and thus bust your run-time :-)

Right. In theory. In practice queryInterface already is blocking it for all but
the most simplistic cases. So the experience in static languages is already ...
less then stellar.

I guess, my point is: Maybe we should focus on the dynamic typed languages? As
they provide something we cant offer with the static typed core development.

To let statically typed languages other than C++ (aka Java) not completely left
our in the rain, it should be possible to generate static wrappers around the
dymanic interface by reflection. E.g. an extension that aquires instances of
all the objects/services interesting to to a extension programmer from an
instance of the office the developer is coding against and uses reflection to
write a static wrapper class offering _all_ the methods and properties of _all_
the interfaces of the service. As this is per-service and not per-interface it
will also spare you the queryInterface madness and actually give you a usable
autocompletion.

This generated wrapper class might not be garantueed to be valid for eternity,
but will likely be valid long enough for all practical proposes. And if it
indeed becomes invalid, all that is needed is regenerating the wrapper class.
This should be "good enough" for RAD -- and if your extension is getting huge,
you should simply go to collaborate more directly with core development.

Best,

Bjoern


More information about the LibreOffice mailing list