Re: shiny uno version, Desktop IDL

On 06/22/2012 04:13 PM, Michael Meeks wrote:
> On Fri, 2012-06-22 at 11:21 +0200, Michael Stahl wrote:
> > 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
>
>         I disagree :-) if we allow a hetrodox understanding of type information
> for the same interface, and we compile that in rather than having it in
> types.rdb (with all it's performance, size & lookup problems)  -and- we
> forcibly bridge all in-process extensions that are not native: certainly
> we can have all three - it is mostly a matter of clever bridging, and
> choosing of good back-compat defaults (that map to zero / whatever we
> pad with).
>
>         If we make UNO more powerful in that way, we can improve things quite a
> bit here.

I'm not sold on the applicability/usefulness of such automatic bridging 
between API versions.  For example, in general there are no "good 
back-compat defaults" for additional method parameters, say, so you 
would end up with arguments of type Optional<T>, which in turn could 
make code implementing such interfaces awkward (while the intention for 
changing the API is making code less awkward, at least some of the time).

Manual bridging, by writing explicit code that tells UNO how to bridge 
among API versions, might help there, but at the cost of adding more, 
typically little-tested code.

Anyway, I'll turn in a LOCon paper on whether/how to do stuff like that 
and at what prize.

> > >         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?
>
>         Sure - tools' IMPL_LINK - would be the broken, degenerate, gross
> case :-) More attractive versions would be g_signal or Qt's signals&
> slots[1], I've used the rather sweet C# bindings of these too to good
> effect; boost has a nice implementation as well anyhow checkout:
>
>         http://en.wikipedia.org/wiki/Signals_and_slots

Not sure what improvements you are looking for over UNO's existing 
listener mechanisms.

Stephan