Re: [boost] [Review] ITL review starts today, February 18th

Subject: Re: [boost] [Review] ITL review starts today, February 18th
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2010-03-01 11:34:57

Hi Vicente,

2010/3/1 vicente.botet <vicente.botet_at_[hidden]>

>
> ----- Original Message -----
> From: "Joachim Faulhaber" <afojgo_at_[hidden]>
>
> > 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/concepts/addability__subtractability_and_aggregate_on_overlap.html
> >
> > 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