Re: shiny uno version, Desktop IDL

On 14/06/12 12:40, Michael Meeks wrote:
> Hi Bjoern,
>
> On Thu, 2012-06-14 at 12:02 +0200, Bjoern Michaelsen wrote:
> > >     [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:
>
>       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 :-)

there are reasons why some methods look like this, it's because you
can't have all 3 of:

1. statically typed interface

2. binary backward compatibility of interface

3. ability to extend existing interface with new optional parameters

the 2 solutions (you may call them workarounds) to this conflict are:

a) the ever popular XFooN interface, for N \elem {2, 3, ...}

b) something like "doIt(sequence<any> parameters)", more likely
   with PropertyValue instead of any (which is in any case essentially
   dynamic typing in a statically typed language)

depending on how often new optional parameters need to be added, either
of these is better; a) in the case when it is rare to add new
parameters, and b) in the case when it is anticipated that new
parameters are likely to be added often.

an example for b) is the use of the MediaDescriptor "service", which is
really just implemented as a sequence<PropertyValue> that is passed to
various loadFromMedium etc. methods; the thing has about 20 or so
optional properties, and i cannot imagine an interface with 20 explicit
parameters, most of which are not mandatory, and many of which are of
type string anyway, to be better (or easier to use) than the current
XComponentLoader.loadComponentFromURL.

of course it may be the case that there are some interfaces that never
actually needed to be extended in this way, and perhaps these could be
better off without sequence<any> parameters, but that should be checked
on a case by case basis.

> > letting the language bindings provide the syntactic sugar around
> > that with reflection and stuff like python metaclasses(*). That
> > would also mean:
>
>       So - syntactic sugar sounds good to me ;-) I'd particularly like a
> built-in UNO, efficient signal/slot mechanism and native language
> bindings for each language [ but particularly C++ ].

can you point me to something existing that is like this "signal/slot"
thing you want?