[phobos] std.base64 replacement

[Shin Fujishiro]

Daniel Murphy <yebblies at gmail.com> wrote:
> On Wed, Oct 13, 2010 at 4:47 PM, Shin Fujishiro <rsinfu at gmail.com> wrote:
> 
> > The biggest reason why I think so is ranges' inaptitude for filtering
> > purposes.  M-N conversions, which happens in base64 and character
> > code conversion etc., can't be supported by ranges without twisted
> > hacks.  Most filters needs to control how many items to read and write
> > *by themselves*.
> >
> 
> 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?

No.  Uh... Let's forget about ranges for the next two paragraphs.

Consider decoding a base64 unit (4 chars) by hand.  You may want to
(a) pull four chars from a source, and decode them into three bytes.
Then, (b) you'll push the decoded bytes to a destination.  Done.

Conversion works naturally if (a) data can be pulled from a source and
(b) converted data can be pushed to a destination.  If either of them
can't be achieved, we need an extra cache to pool dangling data.  The
"control" I wrote meant these two points.

Then, can ranges support pull and push?  No, unfortunately.  They are
restricted to pull *or* push semantics.  Decorator input ranges can pull
data from source ranges, but can't push converted data to anywhere.
Output ranges have similar inconveniences.

So, ranges are not best for conversion drivers IMO.  Ranges are at
their best when used as sources and destinations.  We may support
decorator ranges, but they should not be the main API.

Hey, I'm not dissing ranges nor your implementation. :-)  I'm just
afraid of people making everything ranges in the first place!


Regards,
Shin