Re: [sigc] conditions in libsigc

[Aristid Breitkreuz <aribrei arcor de>]

Am Sonntag, den 02.07.2006, 22:31 +0300 schrieb Paul Pogonyshev:
> Aristid Breitkreuz wrote:
> > Am Freitag, den 30.06.2006, 20:58 +0300 schrieb Paul Pogonyshev:
> > > Hi,
> > > 
> > > I would like to propose conditions in libsigc.  A condition is basically
> > > a boolean vairable plus signal which is emitted each time the variable
> > > state is changed (from true to false or vice versa.)
> > 
> > Sounds useful but I do not think they belong in sigc++. This sounds to
> > me like a special case of a variable that whenever changed emits a
> > signal. Why restrict yourself to bool?
> 
> It is weird to create a separate library with such a small functionality and
> I thought sigc++ fitted it best.  (I.e. it is probably a better fit than e.g.
> Glibmm.)

Very true.

> 
> > >   They are useful in
> > > e.g. GUI design because you can specify a boolean expression, e.g.
> > > sensitivity or visibility, only once and not track when its state changes,
> > > which can be difficult at times.
> > 
> > Are there exception guarantees?
> 
> Well, I didn't think about it :)  That depends on implementation, right?
> 
> > >   In other words, the condition itself
> > > and its state tracking are no longer separated and chances of programming
> > > error are significantly smaller.
> > > 
> > > I volunteer to implement this if you are interested.
> > 
> > I have written a library that does something similar but does NOT track
> > when the state changes. But this is nothing but syntactic sugar anyways.
> > You might want to take a look though:
> > 
> > http://gott.snip-a-lot.de/autodoc/namespacegott_1_1properties.html
> > (documentation only, includes a tutorial but not necessarily in the best
> > style)
> 
> Yeah, but GOTT is heavy, it seems.

You can very well isolate this library. It's header-only in a directory
of its own and part of GOTT simply for my convenience. And because as
you said it's practical for graphical user interfaces.

> 
> Anyway, if you don't think it is good for sigc++, let's not continue this
> discussion.

I am DEFINITELY not the person to decide. I'm no more than a subscriber
of this list. I hate the idea of being guilty of a prematurely stopped
discussion :-/.

> 
> Paul

Aristid