[phobos] std.base64 replacement

[Sean Kelly]

On Oct 13, 2010, at 1:52 PM, Shin Fujishiro wrote:

> I'm sorry but I respond to a part of your message for now.  I'll post a
> reply for the rest later!
> 
> Daniel Murphy <yebblies at gmail.com> wrote:
>>> Input ranges can only support N-1 conversions in a sane way.  They
>>> can read as much items as needed from the 'front' of their underlying
>>> source ranges, but can only expose a single item.
>>> 
>>> Similarly, output ranges are restricted to 1-N conversions.
>>> 
>>> Yeah, I know you can work around the problem by caching several items
>>> inside a decorator range.  It's done in your code and pretty works. :-)
>>> But I think it is showing how ranges are unfit for filtering purposes.
>> 
>> 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.
> 
> So... how?
> 
> To tell a truth, I've tried creating decorator ranges for character code
> conversion and zlib decompression, and both required internal caching.
> I think it's a limitation of the decorator design.

I'd thought so too.  zlib in particular has this issue--the quality of compression is directly related to the buffer size.