Hi Vicente, 2010/3/1 vicente.botet <vicente.botet@wanadoo.fr>
----- Original Message ----- From: "Joachim Faulhaber" <afojgo@googlemail.com>
5) OPERATORS and FUNCTIONS
By default we propagate operator + to combine associated values. This yields to concatenation, if lists, strings, etc. are associated addition, if numbers are associated union, if sets are associated generalized union, if maps are associated. This is [reason 1], why union on sets and generalized union on maps must be expressed to operator +, +=
From the examples, the single type that supports the operators + and += are numbers and strings. Maybe it is not a good idea to use the operators for the library, but just clear names.
For this kind of fundamental semantics, I think using operators is desirable. This makes the code small, elegant and intuitive.
See also:
http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/con...
So again, this design is based on the assumption, that, for a combinable type T, we can identify a primary operation for the combination of it's values and for this primary operations we expect operator + . This is crucial for the combination of maps in the ITL. Maps propagate this
primary
combine function. And as default we always use operator + . Since associated type can be sets, interval_sets and, yes, maps and interval_maps : We must assign operator + to the primary way of combining sets and maps in the ITL. Because, by introducing a generalized addition on maps, we start to propagate the combination operator. The best choice for this? Clearly the archetypal operator that is there for the combination of *something*: operator + .
Have you think about adding the Combiner Trait template parameter not to the container class, but to the container operation (add, substract, ...)?
Yes, I have thought about this. There even are function templates x.add<Combine>(pair) and x.subtract<Combine>(pair). I chose to make them private, because I consider the Combine functor an invariant of the given instantiation of an itl::Map. It is similar to the handling of compare functors for an SortedAssociatedContainer. You can not dynamically change the sorting order at runtime by calling a find<MyOrdering>(key).
Of course this eliminates the use of operators + +=. but IMO is clearer, you add a new element to a map if not ovelap, otherwise the operator use the combiner on the overlaping interval.
for example if I have {[2,4)->5, [6,7)->10, [12, 15)->0}
adding [1, 10)->1) could result in {[1, 10)->1, [12, 15)->0)} if the combiner gives the new value for the overlaping intervals.
Similarly it seems not to make very much sense to change the way in which an interval_map aggregates dynamically. I haven't found use cases for that in years. Best, Joachim