Re: [boost] Formal Review: Boost.RangeEx

Subject: Re: [boost] Formal Review: Boost.RangeEx
From: David Abrahams (dave_at_[hidden])
Date: 2009-03-02 15:13:45

on Mon Mar 02 2009, Arno Schödl <aschoedl-AT-think-cell.com> wrote:

> Dave,
>
>>       r | transform(f) | filter(g) | whatever(h)
>>       = whatever(filter(transform(r, f), g, h))
>
> why this way around? Why not
>
> whatever( h, filter(g, transform(f, r) )
>
> which I don't find much worse than the operator| notation, 

Better than what I cited, but still inferior to operator|

> and it works consistently with anything that expects functions,
> boost::bind, boost::function, whatever other people have already
> implemented that invokes operator(). 

That's indeed a real advantage to function call notation.  On the other
hand, we have libraries like lambda and phoenix that allow us to work
with the operators in a similar way.

> I agree with Rogier that I don't see why ranges are so different from
> doubles, say, that would warrant introducing a new syntax.
>
> And wouldn't concepts in C++0x allow augmenting Ranges with things that can be invoked
> method-style, like
>
> r.transform(f).filter(g).whatever(h) 

You could do that today, but it's got the same coupling problem as named
parameters in Boost.Graph and is solved by Boost.Parameter.  Is there
something in C++0x that causes decoupling?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com