Re: [boost] Formal Review: Boost.RangeEx

Subject: Re: [boost] Formal Review: Boost.RangeEx
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2009-02-25 13:59:23

On Wed, Feb 25, 2009 at 7:07 PM, Vicente Botet <vicente.botet_at_[hidden]> wrote:
>
> From: "Neil Groves" <neil_at_[hidden]>
>>
>> On Wed, Feb 25, 2009 at 5:13 PM, Giovanni Piero Deretta <gpderetta_at_[hidden]
>>> wrote:
>>>
>> (and BTW, what about  renaming 'transformed' -> 'map' and 'filtered'
>>> -> 'filter')
>>>
>>
>> I don't think the suggestion to change transformed is a good idea.
>> transformed is more obviously related to transform, and map is already a
>> standard container.
>
> What about simply 'transform'?
>

If the range variant of std::transform were named 'transform_inplace',
it would work (I wouldn't want two 'transform' with different meaning
in boost, even in different namespaces), but I do not know if anybody
else like it.

>> filtered to filter doesn't sound bad, not does uniqued to unique, as long as
>> it doesn't clash with other names. Perhaps this suggests that they should be
>> kept in the boost::adaptors namespace.

again, the 'unique' name is already taken by the std::unique inplace
semantics, unless the boost variant were to be called unique_inplace.

>
> If you put then in a specific namespace you avoid clashing. If you put them in namespace boost, you need to use concepts or (enable_if). The library contains already some functions at the boost level as begin, end and nobody complains. The algorith library use three level namespace boost::algorithm::sequence for for_each_if. So the user needs
>
> boost::algorithm::sequence::for_each_if(range, f,cnd);
>
> In other words, should the transform function in Boost.Fusion and in Boost.Range and in Boost.Algorithm,
> and .. live in different namespaces?

Right, I forgot that fusion uses the 'transform' name for a non
inplace map. And there is also mpl::transform with the same view
semantics [*]. So there is already an existing practice in boost  and
maybe the inplace std::transform should really be called
transform_inplace ;-)

[*] of course, mpl doesn't really have a choice.

>
> IMHO, Not. All these names must reside in the same namespace and the library must allows to make partial
> specialization of these functions.
> [snip sfinae example]
>
> The user will just do boost::interrupt(act).
>
> If another boost library want to overload  interrupt(T) for other types that do not provide a member interrupt function, the developer needs just to
>
>    template <typename T>
>    typename boost::enable_if<a_specific_condition<T>,
>        void
>    >::type
>    interrupt(T& act) {
>    // ...
>   }
>

I think this would break horribly if two libraries define slightly
overlapping conditions, so I do not think it is a great idea. It might
work with non auto concepts in c++0x.

-- 
gpd