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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Reply via email to