Re: [sigc] conditions in libsigc

[Ulrich Eckhardt <eckhardt satorlaser com>]

On Tuesday 04 July 2006 19:10, Paul Pogonyshev wrote:
> I wrote:
> > > This is getting pretty pointless.  Lets end it here, as an ounce of
> > > code is worth a pound of words.
> >
> > OK.  I'll try to write something.
>
> Here is `something'.

Okay. Let me try to summarise what you wrote there, just to make sure I got it 
right. Apart from what everybody (well, at least me) understood the first 
time, that you want an observed boolean value (like some languages/toolkits 
provide), there are two other important aspects to your code:

1. handle/body separation
The class 'condition' is split into an interface and a pointer to a refcounted 
implementation class. This means that the condition is copyable(!) in pretty 
much the sense that a Java or Python reference is copyable. The copy is not a 
distinct object but all copies refer to the same underlying implementation. 
This makes it possible to create a 'condition' somewhere and pass it on to 
other places with ease.
A simple observed<bool> like I described would be copyable but loose all 
information about connected slots, i.e. it would only copy the underlying 
value, not the rest. I'd probably disallow copying altogether for that since 
it makes little sense.

2. boolean operations
These combine two 'conditions' and yield another condition. This automagically 
combines both the boolean values and the emitted signals of the 
original 'conditions'. This is achieved by a set of utility classes for the 
various operations (and, or, not, xor) and factory functions (in the example 
code it is an overloaded operator+ which combines two conditions).
The suggestion then is that a widget would have such a 'condition' for e.g. 
its visibility, which the user could then combine from whatever other 
conditions should be met to make that widget visible.


So far, so good, I'd be interested in how it would be to program with this 
(you never know if an API is good until you have really used it). I think it 
would not be necessary to touch libsigC++ for now -  rather, such a library 
could be implemented on top of it. It might even be better as part of GTKmm, 
since the use of a single boolean is rather special. On the other hand I 
could also imagine other types being handled in that way, e.g. tri-states or 
other values. In any case I'd present this to the GTKmm people!


One thing I noticed while reading your code: there are two classes that only 
serve to adapt/mediate between a condition and a widget. A simple function 
might have been enough, using bind() to set the parameters.


BTW: someone called me a maintainer of libsigC++, but that is only partially 
true. I indeed 'maintain' (if there is anything to) the 1.x ports for MS 
Visual C++ and also a private (i.e. not part of mainstream) port for MS 
embedded Visual C++ (used as cross-compilation environment for Windows CE 
devices). Other than that, I haven't even touched libsigC++ 2, exactly 
because I still have to maintain code for older compilers that aren't even 
close to compiling 2.x.

cheers

Uli

****************************************************
Visit our website at <http://www.domino-printing.com/>
****************************************************
This Email and any files transmitted with it are intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any reading, redistribution, disclosure or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient please contact the sender immediately and delete the material from your computer.

E-mail may be susceptible to data corruption, interception, viruses and unauthorised amendment and Domino UK Limited does not accept liability for any such corruption, interception, viruses or amendment or their consequences.
****************************************************