Re: shiny uno version, Desktop IDL

On 06/14/2012 01:14 PM, Bjoern Michaelsen wrote:
> 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.

...which we are addressing with the new-style stuff (ever since 2004...)

> 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.

Not even over my dead body.  ;)  What exactly do they offer that we 
cannot provide?

> 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.

How do you generate a static wrapper around a dynamic entity?  You can 
only generate it for a given snapshot of that dynamic entity's behavior. 
 But then, when you assume the entity's behavior is (largely) static 
anyway, why not properly codify it in the first place?

That UNO is (somewhat) statically typed does not mean that dynamic 
languages cannot have a binding to it that feels (largely) natural. 
Just like shortcomings of some common statically typed languages do not 
mean that "statically typed" implies "verbose" or "awkward."  But 
turning things around, making the foundations of UNO less statically 
typed than rather making it more so, is a wrong approach IMO.

> 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.

This is not about "RAD," this is about "software development."  Yay, on 
to a flamefest!  ;)

Stephan