On Sun, Jul 20, 2008 at 9:37 PM, Brian Davis <bitminer@gmail.com> wrote:
I looked through boost and if there is a library or facility for data binding in boost I could not find it... So I created and am submitting a simple example for review.
[snip]
Dataflow provides the event model data_binding provides the means to do data conversion between events.
Hi Brian, You are right in that this combines two problems - one is binding values together (the part that is very appropriate for Dataflow), and the other is transformations of values (which is useful in itself). Even though these could be left as orthogonal concepts, perhaps gluing these two together might also be interesting. I have tried to tackle the value/domain transformation problem a while back, inspired by Brook Milligan's (CC-d) probability library (which can nicely transition probability values between linear and log domains). My attempt at a generic domain-transformation solution relied on a "pivot" type. That is, you could transition from any domain to any other domain as long as both specified how to transition to some common, "pivot" type. This is where it is different from your solution, where you specify pairwise transformations (I think in my implementation you could also specify direct transforms, but I don't remember). E.g., here is how you implement a log domain: http://pastebin.com/f6dd9c7d ... and some test code: http://pastebin.com/f160d91e9 I think you can download the whole thing packaged with other stuff at: http://ame4.hc.asu.edu/amelia/download/ Brook Milligan also worked on a generic domain transformation library, so he might comment on this as well. There is also the Boost.Units library which might offer transformations for some cases. Going back to dataflow+transformations... If the two were left separate, we could implement the binding (no transformations) part easily as a part of the Dataflow library. That would mean you can only bind together values of the same type/domain. I think it basically reduces to a shared_ptr if you don't care about getting notified about a change. On top of that, then, when you need bound values to exist in different domains (e.g., Celsius, Farenheit, sensor), each value can do it's own transformation to/from the shared value (think star topology). This is similar to the "pivot" type concept. Now, there are times when this would not be desirable. One case is when the transformations to the pivot type lose precision, so you'd rather connect the bound values in a ring of some sort (or some other connected component in graph terms), and each connection would have transformations (one for each direction) built into it. Once a value gets changed, the network would need to decide on which (one) path to use to update each other value. Also, I think there are some interesting lazy evaluation possibilities (don't calculate the transforms until needed). Anyway, I think it would be interesting to try to add some of this to the dataflow library. Would you prefer the "star topology" solution, or the other one (similar to yours) with arbitrary connection/transformation topologies? (first can be seen as a special case of the second, but maybe has a simpler implementation)? Stjepan