Re: [boost] Slots and signals: Listening to a value

From: Johan Torp (johan.torp_at_[hidden])
Date: 2007-05-24 03:40:28

> Date: Wed, 23 May 2007 17:48:20 -0400
> From: Edward Diener <eldiener_at_[hidden]>
> Your idea is essentially a 'property' whose change in value triggers a
> notification event. Both Java and dotnet have such functionality
> combined with the idea of Javabean properties in the former and dotnet
> component properties in the latter.

Do you have any links describing .NET and Javas implementations? I've
googled a bit and have been able to find some information but no
proper reference or rationale.

> I have worked on my own with the idea of a C++ 'property', but not with
> enough personal satisfaction to put it in the sandbox or submit it to
> Boost. Reece Dunn, I believe, has submitted his own idea of a C++
> 'property' as an implementation to the sandbox in the past. Obviously
> notifiers as events can be built into the idea of a C++ 'property'
> whenever the property changes and Java goes so far as to actually build
> into their idea of a Javabeans  'property' the idea of being able to
> cancel the change before it happens by an event ( signal ) listener (
> slot ).

I had a quick glance at these and I believe that this is not what I'm
looking for.

Properties are exposed member variables, I do not believe it is a good
idea to expose members. The typical usage for this class, let's call
it observable_value, is:

class logic_class
{
  const observable_value<bool>& GetSomeState() const;
  const observable_value<money_class>& GetCredits() const;
};

Setters needn't be supplied and if they are, they can do more things
than just setting an internal observable_value variable.

> I do not think the idea of an event whenever a 'property' changes should
> be part of the signals library itself but it can, and should IMO, use
> the signals library whenever the change occurs. I think the idea itself
> of a signalled 'property' change belongs in its own separate
> implementation, since the signals library is sufficient enough providing
> just the notion of signals and slots ( or events and handlers as others
> may call it ).

This is probably a better idea. This simple class could, with a lot of
work, be extended into a library which could support the standard
collections and other user defined value types as long as all
non-const methods are wrapped to detect state changes. I.e. we would
need to implement a non-const wrapper iterator for STL collections.