Re: shiny uno version, Desktop IDL

On Thu, Jun 14, 2012 at 10:22:44AM +0100, Michael Meeks wrote:
>       So - as an example; I would love a:
>
>       any  getConfigKey([in] string path);
>       void setConfigKey([in] string path, [in] any value);
>
>       Cheesy, incomplete - if you want more you have to go to the real source
> - but, at the end of the day it would cover 99% of the simple, extension
> use-cases I think. IMHO there are a set of objects and features that are
> rather unpleasant to use & find that we could make much easier in this
> way. Another example might be opening a stream via the ucb - which could
> be wrapped with a single, simple 'fopen' style method.
>
>       Similarly focusing on scripting bindings we have:
>
>     com::sun::star::lang::XComponent getCurrentComponent();
>
>       I would prefer that to be:
>
>     [property] com::sun::star::lang::XComponent activeDocument;

An even more radical approach would be assuming properties to just be a dynamic
string->any map. Python allows mapping those to native attributes with:

 http://docs.python.org/reference/datamodel.html#object.__getattr__

and friends. Its -- ahem "suboptimal" -- from the performance perspective, but
we made contributing to upstream for performance critical tasks easier quite a
bit, so maybe we should allow ourselves to simplify the extension/scripting
interface too? 

I wonder how much of our scripting functionality can be made available with no
static typed interfaces and essentially only map, sequence and "Any" as as
static datatypes in UNO and letting the language bindings provide the syntactic
sugar around that with reflection and stuff like python metaclasses(*). That
would also mean:

- No more idl writing, compiling and throwing around as binding, 
- No more 'I published a sucky interface, but we are stuck with it for eternity now' 

The limitations wouldnt hurt for Python as it is dynamic enough. It wouldnt
hurt C++ assuming all relevant service implementations are C/C++ and one could
use that directly instead of UNO bindings. Java might suffer quite a bit as a
static typed language not being the native language of the service
implementations. IMHO it is still worth consideration.

Just some random ramblings.

Best,

Bjoern


(*) http://www.python.org/doc/essays/metaclasses/