Date: Wed, 23 May 2007 17:48:20 -0400 From: Edward Diener <eldiener@tropicsoft.com> 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.