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

From: Edward Diener (eldiener_at_[hidden])
Date: 2007-05-24 08:53:14

Johan Torp wrote:
>> 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.

For Javabeans you can look at http://java.sun.com/products/javabeans/ . 
For dotnet components you can look at MSDN online at 
http://msdn2.microsoft.com/en-us/library/default.aspx and search for 
'property'.

> 
>> 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.

Properties in Java and dotnet are not exposed member variables. Rather 
they are member functions which get and/or set values. The advantage of 
a property is that one can use member data access notation, ie. avalue = 
someObject.someMember for getters and someObject.someMember = avalue for 
setters, and one is internally calling a member function to get or set 
some value. The value itself does not even have to be a data member but 
can be retreived or assigned on the fly. For many C++ programmers 
properties are merely syntactic sugar for calling a getSomeValue and/or 
setSomeValue member function, which in essence it is, but it regularizes 
the syntax in a consistent way.

> 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.

In the properties of Java and dotnet a property can be just gettable and 
not settable. Since they are member functions, one can trigger events ( 
signals ) when they are called, just like any other member functions.

Your notion is essentially to trigger an event when a "property" 
changes. I think that is valuable but I just wanted to point out to you 
that it already has precedents in other implementations. Of course Java 
and dotnet use their own event-driven implementations, but the Boost 
signals library is as good or better than either of them.

> 
>> 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.

Good luck, but do look into the idea of 'property' if you like. In the 
implementations I mentioned it basically encapsulates the concept of a 
value of an object which is retrievable or changeable and which may, if 
the programmer so chooses, trigger an event to notify of the change in 
the value.