Subject: Re: [boost] Formal Review: Boost.RangeEx
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2009-02-25 12:13:11
On Wed, Feb 25, 2009 at 5:32 PM, Neil Groves <neil_at_[hidden]> wrote:
> Dear Giovanni,
> On Wed, Feb 25, 2009 at 4:21 PM, Giovanni Piero Deretta <gpderetta_at_[hidden]
>> On Wed, Feb 25, 2009 at 5:00 PM, Neil Groves <neil_at_[hidden]>
>> > Dear Sir,
>> > On Wed, Feb 25, 2009 at 3:36 PM, Rogier van Dalen <rogiervd_at_[hidden]
>> >> I am not sure I understand the motivation for the operator| syntax. Why
>> >> couldn't
>> >> vec | boost::adaptors::reversed | boost::adaptors::unique
>> >> be written
>> >> boost::adaptors::unique (boost::adaptors::reversed (vec))
>> >> ? I think this contrast would be fairer than what the documentation
>> >> currently has. Is there a reason why it is not possible to provide both
>> >> syntaxes? The pipe syntax is nice, but sort of restricts operations to 1
>> >> range in, 1 range out. Relatedly:
>> > In the adaptors section the preference for operator| is documented. It
>> > simply chains better in my opinion.
>> > I do provide both alternatives, for example
>> > boost::make_uniqued_range(rng) is equivalent to rng | uniqued
>> IMHO the make_... syntax for range adaptors is horrible (i don't even
>> like the past tense, why not just unique?).
>> But why use two different names in the first place? Why not make
> I simply dislike lots of overloading particularly where the semantics are
> different. Perhaps the semantics aren't that different.
IMHO they are the same thing. I think of operator() in ' a | b' as
'b(a)', i.e as a generic apply operator.
>I had considered
> creating a range adaptor to be highly different to applying an algorithm,
> perhaps I over-emphasised this distinction when making the decision.
FWIW, I have code like this:
total = ( r | filter(_r, f) | map(_r, m) | accumulate(_r, zero, a) );
i.e. I don't have a strong distinction between adaptor and algorithms.
>> 'some_functor(range) ' eqivalent to 'range | some_functor'
>> (i would actually go for the syntax 'range | some_functor(_r)', where
>> _r is a placeholder for the range; This is usefull for adaptors that
>> actually have other parameters in addition to the range itself)
> I would always prefer the '|' syntax to any normal function invocation
> however it is spelled. In my opinion, it combines much more elegantly.
I use the '|' syntax a lot when writing long pipelines because it
avoids long nested expressions (it also reads better left to right).
But when I need a simple map or filter before passing a range to an
algorithm I usually just go for the function call variant.
Also, if you have a range of ranges and want to map the nested ranges,
having 'transformed' as a function object becomes very useful:
range_of_ranges | transformed(transformed(f)));
(and BTW, what about renaming 'transformed' -> 'map' and 'filtered'