[phobos] std.base64 replacement

[Masahiro Nakagawa]

Hmm... OK.

Please give me your implementation.
I will merge your code into base64 module as Encoder that return type of  
front is char(Decoder too).


Masahiro


On Tue, 12 Oct 2010 19:17:28 +0900, Daniel Murphy <yebblies at gmail.com>  
wrote:

> 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.


-- 
/+
  + Masahiro Nakagawa (repeatedly at gmail.com)
  +/