<br><div class="gmail_quote">On Wed, Oct 13, 2010 at 4:47 PM, 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">The biggest reason why I think so is ranges' inaptitude for filtering</div>
purposes. M-N conversions, which happens in base64 and character<br>
code conversion etc., can't be supported by ranges without twisted<br>
hacks. Most filters needs to control how many items to read and write<br>
*by themselves*.<br></blockquote><div><br></div><div>I'm not sure what you mean about having control over the number of items processed. Do you mean that because of caching more bytes can be encoded/decoded than are ever used?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Input ranges can only support N-1 conversions in a sane way. They<br>
can read as much items as needed from the 'front' of their underlying<br>
source ranges, but can only expose a single item.<br>
<br>
Similarly, output ranges are restricted to 1-N conversions.<br>
<br>
Yeah, I know you can work around the problem by caching several items<br>
inside a decorator range. It's done in your code and pretty works. :-)<br>
But I think it is showing how ranges are unfit for filtering purposes.<br>
<br></blockquote><div><div><div>I see that caching may be undesirable in some situations, but this adapter (and I assume most others) can be implemented perfectly well without it. It's a flaw in implementation, not a limitation of ranges.</div>
<div><br></div><div>When using a output range, I think there is an expectation that output has been completed after each call to put, which does prevent you from designing a range that only produces an output every second call to put. (I might be imagining this expectation, I haven't seen/written very much code using output ranges)</div>
</div></div><div><div>When using forward ranges this problem doesn't exist, because they guarantee you are only consuming your view of the data.</div></div><div><br></div><div><div><div>What other problems prevent ranges from modelling M:N filtering properly? (without twisted hacks of course)</div>
</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">I don't see much benefit to make filters decorator ranges in the first</div>
place. You can implement them, but decorator ranges should be<br>considered extensions to core filters implemented as Masahiro's way.<br><br>So, I believe that Masahiro's encode(src,sink) design wins. His base64<br>
filter has a control over the number of bytes to process, and hence no<br>
need for extra caching.<br>
<br>
Of course, decorator ranges are useful in some situation, and we'll<br>
eventually need them. But they should never supersede Masahiro's<br>
filters.<br><font class="Apple-style-span" color="#888888"><br></font></blockquote><div><div><br></div><div>I don't see any real differences between the lazy range design and the conversion function design, apart from the usual lazy vs eager factors of performance, memory consumption and interface simplicity.</div>
</div><div><br></div><div>I tend to see the lazy solution as the primary solution, and the conversion function as an alternative implementation optimized for speed and/or usability.</div><div>One similar example is std.string.split vs std.algorithm.splitter.</div>
<div><br></div><div>That being said, I think we do need both, as the conversion function should be more efficient and simpler to use for the most common case (buffer -> buffer).</div><div>I'd hate to have to use</div>
<div> copy(Base64.decode(inputbuffer), outputbuffer);</div><div>over</div><div> Base64.decode(inputbuffer, outputbuffer);</div><div>just as I'd never want to write</div><div> copy(repeat(5), buffer);</div><div>over</div>
<div> fill(buffer, 5);</div><div><br></div><div><br></div><div>So, what am I missing? What does a conversion function design have to offer over that a range can't do?</div><div><br></div><div>Thanks, Daniel.</div></div>