Re: [boost] Slots and signals: Listening to a value
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.
Johan Torp wrote:
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.
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.
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'.
Cheers, I will look into these later on.
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.
You're absolutely right. I will definitely read up on properties as they are a similar construct, thanks for the input. What I want to achieve is different though. I am not interested in adding syntactic sugar. I also think properties doesn't communicate clearly what they do. A name like observable_value<bool> is much clearer. Best Regards, Johan
participants (2)
-
Edward Diener -
Johan Torp