Re: [boost] data_binding

From: Brook Milligan (brook_at_[hidden])
Date: 2008-07-26 18:19:14

Brian Davis writes:
 > Yes that is what I want.  This is what I mean by data binding.  A bunch of
 > values can be bound together so that when one changes they all change
 > instead of having set a value to call each conversion function in a chain.

At this point I'm thinking I agree with Stjepan.  To me this seems
like a combination of two distinct things:  passing messages about
when things happen (i.e., your binding stuff) and interspersing
conversions when necessary.  Both your approach and the DataFlow
approach seem aimed at the former.  My Domain approach is clearly
aimed at the latter.  From my (quick) look over your code it looks
like your types could be my domains and that whenever transformations
were required they would either just happen or you could explicitly
make use of my domain_cast() function.  Thus, there might be a very
simple merger that would handle all the conversions easily and behind
the scenes.

 > Users of the libraries often become the extenders of the library when
 > ultimately it does not meet there needs.  All libs suffer from this.  So
 > making it extensible is important to allow the user to extend it to their
 > domain.  This library is then a library for library developers for domain
 > specific transformations?

Absolutely, they do.  Indeed, even library writers play the two
different roles of developer and user.  I don't imagine too many
people develop libraries purely for the fun of doing so with no intent
of using them themselves.

The entire goal of my Domain library is to make the development of
these sorts of libraries systematic and idiomatic.  If it succeeds,
then building libraries of types representing related domains becomes
much simpler.  Of course, the details of conversions and so on still
lies in the developers domain and could be very hard in certain
cases.  However, the remainder of the challenge could be abstracted
away so that only the essential elements are left to the library
developer.

 > Give the demo code a try if you haven't... Either you will be aghast by what
 > I have done or find it a very nifty bit of code.  I guess there will be very
 > little middle ground for those who see how it works.

I've looked it over, but not yet tried it.  I'll see if my thoughts
above are actually correct about bridging them easily.

 > What I mean by 1 to 1 is that if no transformation functions are specified a
 > values A set and bound to value B will be equal 1:1.  If you set A to 1 B
 > will be 1 if you set B to 45 A will be 45.  What I mean by compiler errors
 > waiting to happen is that there is not type checking for primitive types (it
 > is as was only a simple example of what I had in mind.) so if you pass in T1
 > = float and a class for T2 without transformation functions you will get
 > compiler warnings when you set A to 2.34 ... what does the class B equal?
 > ... compiler errors.

I presume by this you mean that the value types A and B are
interconvertible by your use of numeric_cast?  All my types are more
complex than just the value type; they carry their domain information
as well.  Thus, there is no such thing as having two different domains
being interconvertible without an explicit conversion.

 > Out of curiosity do you think this library could support time domain
 > transforms to Z-transforms and  S-transforms.  How complex a transformation
 > do you think it will support?

Absolutely.  There is no inherent limit to the types of conversions
possible.  You just have to make the conversion functions available.

One way to view this is as a generic type-tagging and dispatching
system that gives the generic code a systematic means of figuring out
what to do.

 > I help where I can. Provide input where I can and hope it helps.

Thanks for your input already.  I'm getting a clearer picture of how
the two sets of ideas might mesh.

Cheers,
Brook