On Wed, Feb 25, 2009 at 7:07 PM, Vicente Botet <vicente.botet@wanadoo.fr> wrote:
From: "Neil Groves" <neil@grovescomputing.com>
On Wed, Feb 25, 2009 at 5:13 PM, Giovanni Piero Deretta <gpderetta@gmail.com
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