Re: [boost] Formal Review: Boost.RangeEx

Subject: Re: [boost] Formal Review: Boost.RangeEx
From: Joel de Guzman (joel_at_[hidden])
Date: 2009-03-01 21:01:59

Joel de Guzman wrote:
> Kai Schroeder wrote:
>>
>> As nobody has mentioned it yet, I would like to point out that boost:gil
>> already uses the _view ending. Quoting from the documentation:
>>
>> An image view is a generalization of STL's range concept to multiple
>> dimensions. Similar to ranges (and iterators), image views are shallow,
>> don't own the underlying data and don't propagate their constness over 
>> the
>> data. For example, a constant image view cannot be resized, but may allow
>> modifying the pixels.
>>
>> GIL uses names like greyscale_view, nth_channel_view, planar_rgb_view. 
>> Using
>> 'ed' style naming one could use names like greyscale_converted,
>> nth_channel_selected. I am not sure what naming scheme is better but some
>> consistency within boost would be nice.
> 
> Let me add that both Fusion and MPL also use _view to name views.
> It's so obvious and natural. OTOH, 'ed'? Duh! ;-)
> 
> For the sake of consistency with Boost libraries, please name it
_view.

Here's a suggestion:

In fusion, all algorithms are lazy, so algorithms' spellings are as-is.
The _view suffix pertains to the object's class returned by the
algorithm, not the algorithm itself. For example:

     transform(s, f) --> transform_view<S, F>

If Fusion had both lazy and immediate algorithms (again Fusion has only
the lazy variants), I'd place the lazy algorithms in a separate namespace.
One doesn't usually combine lazy and immediate algorithms, right, no?
I think I'd rather see something like:

     {
       using range_ex::transform; // immediate
       transform(s, f);
     }

     {
       using range_ex::view::transform;
       transform(s, f);
     }

Or some such.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net