[boost] Re: Library Proposal: Event-Driven Values

From: Nicolas Fleury (nfleury_at_[hidden])
Date: 2003-06-21 13:00:29

Roland Richter wrote:
> Dear Nicolas,
> 
>  sorry for the late reply. Some other projects try to keep me busy.

And sorry for the late answer, I was in vacation

>  First, I'd like to mention that in German-speaking countries, EDV
>  is a very common acronym for "Elektronische Datenverarbeitung"
>  ("electronic data processing"), hence the library name might be
>  somewhat confusing.

Noted.  I'm rewriting the library with a much simpler interface and 
overloading operators instead of all these sum_, diff_, etc. values and 
I expect the name to make less sense in the end.

>  I think that your ideas lead into two rather different directions,
>  depending on whether these "event-driven" values
>    (a) actively update their related values whenever changed, or
>    (b) are passive and do nothing until their value is fetched.

Agree.  I'm interested in the a) for my part, since I want the use of 
these values in widgets, for example, to be passive.  I mean to never 
check for a change in a value, but instead connect a signal to a 
callback for each change.  With my (modest) experience, it's far less 
resource-consuming.

However, I think there's a place for the b) case, and the complicity 
between the two ways should be maximised.

>  [...]

I totalle agree with your examples, and that's the syntax I realized was 
the best few weeks after my post.

>  For a symbolic math package in C++, I'd point you to http://www.ginac.de

I'll take a look.  Thx.

>  I guess, however, that your main interest lies in variant (a),
>  "event-driven" (opposed to "lazy evaluated") values, that is, in
>  implementing some special form of the Subject/Observer pattern,
>  based on boost::signals.

Exactly.

>  For reasons I pointed out above, this would just make sense if your
>  main focus is *not* on updating other values, but on triggering some
>  action, like this:
> 
>    void print_me( int i )
>    {
>      std::cout << i << std::endl;
>    }
> 
>    value<int> i( 6, print_me );
>    i = 42;  // Prints 42 to stdout.
> 
>  In other words, value<Type> would be some type where construction,
>  assignment, and maybe destruction would call some signals. This might
>  include, but is not limited to, updating other values.

The current version have a signal for value change and destruction.  I 
could also add a signal for "redefinition" (or assignment).  The 
value-change signal minimizes the updates (I assume we are talking about 
the non-lazy values).  The shortcut of passing a callback directly in 
the constructor could be a good idea.

>  Such a class might indeed be helpful, because notifications often occur
>  if a value has changed; so this would simplify things. However, I doubt
>  whether it pays off to invent all those sum_, diff_, sync_, 
> and_so_on_value's
>  in an "event-triggers-update-of-values" way.

I agree.  Some "stuff"_value remains for now, but could be removed also. 
  For example, the ostringstream_value:

ostringstream_value<std::string> str;
value<int> i(4), j(6);
str << i << " << " << j << " => " << (i << j) << '\n';

For now, it's simpler for me to have a subtype, but partial 
specializations or policies could also be used.

Regards,

Nicolas