[phobos] std.base64 replacement

[Daniel Murphy]

On Tue, Oct 12, 2010 at 7:18 PM, Masahiro Nakagawa <repeatedly at gmail.com>wrote:

> Yes, your range doesn't need allocation.
> However, users eventually need to store the result returned from the range
> to the buffer allocated by themselves.
> How to use the encoded / decoded result?
>
> "copy(encode(data), buffer)" seems to be equivalent to 'encode(data,
> buffer)'.
>
> Sorry, I don't almost see the merit of your proposal.
> Base64 is simple(ubyte[] -encode-> char[], char[] -decode-> ubyte[]).
> Your range seems to be over-generalization to Base64...
>
> P.S.
> encode(InputRange, OutputRange) becomes a new function candidate for no
> allocation.
> Of course, decode too. These are inspired by your range.
>
>
> Masahiro
>
> I guess it's the difference between an function that works on ranges and a
range that adapts data.  I assumed the latter would be the best choice for
linear encoding/decoding of a data stream.  I don't think there's a
precedent to follow on this yet.
The main use case that won't work with this design is when the output is
done by a function, not another output range.

eg.
sendOverNetwork(base64Encode(lazyReadFromFile(Filename)));

I don't see how this can be done without allocation when the output method
does not provide an output range.

The data can also be piped through other conversion or encoding ranges.
eg.
auto uuencoded = array(uuencode(base64Decode(inputdata)));

auto encdata = base64Encode("1,2,3,4");
foreach(n; map!(to!int)(splitter(base64Decode(encdata), ',')))
{
    // do something with n
}

I guess what I'm saying is that data doesn't always end up in an output
range, or in a newly allocated array.
Maybe this is way more general than is needed, but I see it fitting the
other range designs in phobos much more closely.

Daniel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101012/1a32c11b/attachment.html>