Re: [boost] Slots and signals: Listening to a value
Looks good to me. You might consider a few minor additions:
- A copy constructor for signalling_value, that just copies the underlying value - A copy assignment operator for signalling_value, that just copies the underlying value Both should definitely be there.
- A conversion to const T& (same functionality as get) - An assignment operator that takes a const T& (same functionality as set) I think I prefer forcing users to be specific about what they do, in this case to point out that they are not just setting a value but also possibly signalling receivers. On the other hand, enabling these two features would allow users to treat this class as a regular value in generic programming. Which do you think is better?
4. Do you have a better naming suggestion? Did you consider "observable_value"? Or even just "observable"?
I did, but I wanted to point out that I was using signals and slots. Observable would be great if it was in the namespace boost::signals. Do you think this class might be useful enough to be added to boost slots and signals? Best Regards, Johan Torp
Johan Torp <johan.torp <at> gmail.com> writes:
Looks good to me. You might consider a few minor additions:
- A copy constructor for signalling_value, that just copies the underlying value - A copy assignment operator for signalling_value, that just copies the underlying value Both should definitely be there.
- A conversion to const T& (same functionality as get) - An assignment operator that takes a const T& (same functionality as set) I think I prefer forcing users to be specific about what they do, in this case to point out that they are not just setting a value but also possibly signalling receivers. On the other hand, enabling these two features would allow users to treat this class as a regular value in generic programming. Which do you think is better?
I'd rather have the overloads. I was actually playing around with something similar recently, and that is how I was doing it. As for explicitly telling the user that they will be sending a message with the set call, I don't think set really tells you anymore as a user than = about how messaging is occurring. Further, as a setter of a value, I rarely care whether an event will be sent or not. I only care about that when I am also the receiver of the message, but at that point I should already know they are tied together, since I hooked into the slot. Jared McIntyre
participants (2)
-
Jared McIntyre -
Johan Torp