On Wed, Feb 25, 2009 at 5:32 PM, Neil Groves <neil@grovescomputing.com> wrote:
Dear Giovanni,
On Wed, Feb 25, 2009 at 4:21 PM, Giovanni Piero Deretta <gpderetta@gmail.com
wrote:
On Wed, Feb 25, 2009 at 5:00 PM, Neil Groves <neil@grovescomputing.com> wrote:
Dear Sir,
On Wed, Feb 25, 2009 at 3:36 PM, Rogier van Dalen <rogiervd@gmail.com wrote:
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. <snip>
'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' -> 'filter') -- gpd