bearophile wrote:
> Dejan Lekic:
>
>> Dear D community, I do not know about You, but I certainly do
>> not like writing code like:
>>
>> inRange.fooRange(param).barRange.
>> .bazRange(param1, param2).outRange;
>
> I suggest to format it this way, it's more readable:
>
> auto something = inRange
> .fooRange(param)
> .barRange()
> .bazRange(param1, param2)
> .outRange();
>
>
>> Therefore I would like to know what do you think about the idea
>> of having additional operator exclusively made for ranges? This
>> operator would make it obvious that data are "streamed" (lack
>> of better term) among ranges.
>>
>> The first name I could come up with was "opArrow" but "opData"
>> could also be okay, and operator would be either "~>" or "->".
>>
>> This would give us an obvious, unambiguous statement:
>>
>> Console.in ~> filter1(param) ~> fooRange ~> Console.out;
>> // Console is an imaginary class/struct
>
> I think it doesn't give a significant improvement. But maybe
> there are more interesting use cases.
>
> I'd like D ranges to support the "~" (using a template mixin to
> give them such operator), that acts like chain. So instead of
> writing:
>
> range1.chain(range2)
>
> You write:
>
> range1 ~ range2
>
> It's also nice to have lazy lists, maybe based on fibers, with
> few operators to concat them, etc.
>
> Bye,
> bearophile
I already did try using the tilda operator for a while, then I realised that
people are getting confused thinking the line is concatinating strings, then
then realise those are ranges... That is exactly the reason why I asked the D
community what they think about having a new operator only for ranges...
I also do what you suggest quite a lot. In fact I almost write it the same way
you do in your example. But think about potential scenario when you give
parameters as members of some structure:
auto something = inRange
.fooRange(someObject.someMember.membersMember)
.barRange(SomeClass.staticMember)
.bazRange(/* etc */)
.jarRange(param1, param2)
.outRange(/* etc */);
Moreover, what if developer does not add "Range" to the name (typical case)?
Imagine confusion with such UFCS methods and properties...
--
Dejan Lekic - http://dejan.lekic.org
