Re: [boost] Formal Review: Boost.RangeEx

Subject: Re: [boost] Formal Review: Boost.RangeEx
From: Neil Groves (neil_at_[hidden])
Date: 2009-02-25 11:32:58

Dear Giovanni,

On Wed, Feb 25, 2009 at 4:21 PM, Giovanni Piero Deretta <gpderetta_at_[hidden]
> wrote:

> On Wed, Feb 25, 2009 at 5:00 PM, Neil Groves <neil_at_[hidden]>
> wrote:
> > Dear Sir,
> >
> > On Wed, Feb 25, 2009 at 3:36 PM, Rogier van Dalen <rogiervd_at_[hidden]
> >wrote:
> >
> >> On Fri, 2009-02-20 at 13:28 +0100, Thorsten Ottosen wrote:
> >> > Dear Developers and Users,
> >> >
> >> > It's my pleasure to announce that the review of Neil Groves' RangeEx
> >> > library starts today and lasts until March 3, 2009.
> >>
> >> That's great news! I've much anticipated this library, since I'd
> >> hand-rolled similar components a long time ago. I hope to submit a
> >> formal review, but before I do, I hope to understand the motivation for
> >> the design better. I hope this is allowed within a formal review. This
> >> is related to my question at
> >> <http://lists.boost.org/Archives/boost/2008/07/140514.php>.
> >>
> >> 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. 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. I like
the make_XXX_range because I instantly recognise that this creates a range
adaptor. However I personally strongly prefer the '|' syntax. I'm trying to
give everyone what they want. I am reluctant to use exactly the same name,
but I am open to change from make_XXX_range. It is of course absolutely
trivial for anyone to provide exactly their own wrapper function to please
their own taste.

>
> '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.

>
> --
> gpd

Thanks for the comments,
Neil Groves

>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>