<br><br><div class="gmail_quote">On Thu, Oct 14, 2010 at 7:48 AM, Shin Fujishiro <span dir="ltr"><<a href="mailto:rsinfu@gmail.com">rsinfu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br></div>
Conversion works naturally if (a) data can be pulled from a source and<br>
(b) converted data can be pushed to a destination. If either of them<br>
can't be achieved, we need an extra cache to pool dangling data. The<br>
"control" I wrote meant these two points.<br>
<br>
Then, can ranges support pull and push? No, unfortunately. They are<br>
restricted to pull *or* push semantics. Decorator input ranges can pull<br>
data from source ranges, but can't push converted data to anywhere.<br>
Output ranges have similar inconveniences.<br>
<br></blockquote><div><br></div><div>Sorry for being slow, I think I understand what you mean now. :)</div><div><br></div><div>Ranges typically model one iteration of an algorithm, and this works best if each iteration reads N items and outputs 1. Is this along the right lines?</div>
<div>I understand that pushing converted data is part of the conversion process, but that is not the only way to do it.</div><div><br></div><div>The conversion function approach works when you want to convert the data, then use it. I'd assume this is the common case.</div>
<div>useConvertedData( convert( originalData ) );</div><div>or</div><div>convert(originalData, buffer);</div><div><br></div><div>The range approach works better when you want to do something with your data as if it was the converted data.</div>
<div><br></div><div>find( converter(originalData), something );</div><div>auto n = calculateChecksum( converter(originalData) );</div><div><br></div><div>Both are forms of conversion and each is most useful in different situations.</div>
<div><br></div><div>Base64 encoding/decoding may be an exception, but you can describe the process of getting the next byte/char fairly easily.</div><div><br></div><div>Encode: Get the next 6 bits from the input -> find char code -> yeild char</div>
<div>Decode: map chars to the values they represent -> get the next 8 bits -> yeild ubyte</div><div><br></div><div>Converting CAN be defined in terms of getting the next piece of converted data, and this is the only method ranges properly support.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
So, ranges are not best for conversion drivers IMO. Ranges are at<br>
their best when used as sources and destinations. We may support<br>
decorator ranges, but they should not be the main API.<br>
<br></blockquote><div><br></div><div>I'm quite happy with that. It does seem like conversion functions cover the most common case with better syntax and performance, with a loss of flexibility. I don't mean to argue for shunning conversion functions in phobos, just providing equivalent ranges where we can.</div>
<div><br></div><div>What I meant earlier when I said that I think of ranges as the primary implementation, is that I feel ranges are a closer representation of the algorithm being used, where a conversion function represents the process of applying the algorithm to data. I don't mean we should tell people not to use the conversion functions.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hey, I'm not dissing ranges nor your implementation. :-) I'm just<br>
afraid of people making everything ranges in the first place!<br><br></blockquote><div><br></div><div>Of course!</div><div>I want ranges everywhere they make sense, and would like conversion functions where they make sense. I just happen to believe both do in this case! I don't want to force the use of ranges anywhere they make code inefficient, uglier or more complicated.</div>
<div><br></div><div>Daniel.</div></div>