shiny uno version, events / signals / slots

[Stephan Bergmann]

On 07/13/2012 03:53 PM, Michael Meeks wrote:
> On Fri, 2012-07-13 at 14:27 +0200, Stephan Bergmann wrote:
>>> 	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.
>
> 	Ease of declaration, use, type safe argument passing and succinctness.
>
> [snip]
> IDL:
> 	event somethingChanged([in] string aName, [in] long nValue);
>
> C++ to emit:
> 	inteface->somethingChanged.emit( "foo", 3 );
>
> C++ to listen:
> 	void handleChanged( const rtl::OUString &aName, long nValue);
> 	...
> 	interface->somethingChanged.connect(mem_func(*this, handleChanged));
> [/snip]
>
> 	Where the C++ piece is inspired by the std::sigc bindings - which are
> somewhat complicated, but potentially re-usable. The above is notably
> less verbose than the existing DECL_LINK horror, and should work nicely
> cross-platform too (like sigc).

...where DECL_LINK is independent of UNO

[...]
> 	IMHO that makes a rather pleasant contrast with the existing UNO
> listener implementation logic - but perhaps I'm missing something there;
> IIRC you need to declare and implement misc. interfaces on either side,
> your a custom listener interface, and more (?).

Right, what you save compared to current UNO is that on the listener's 
end you do not need to explicitly implement a specific UNO interface 
(instead, you only need to explicitly implement a function with a 
specific signature).

So what one would gain is improvement in ease of declaration and use (by 
increased succinctness).  Type safe argument passing would be just as 
type safe as today.

Stephan