[phobos] std.base64 replacement

[Daniel Murphy]

On Thu, Oct 14, 2010 at 7:48 AM, Shin Fujishiro <rsinfu at gmail.com> wrote:

>
> 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.
>
>
Sorry for being slow, I think I understand what you mean now. :)

Ranges typically model one iteration of an algorithm, and this works best if
each iteration reads N items and outputs 1.  Is this along the right lines?
I understand that pushing converted data is part of the conversion process,
but that is not the only way to do it.

The conversion function approach works when you want to convert the data,
then use it.  I'd assume this is the common case.
useConvertedData( convert( originalData ) );
or
convert(originalData, buffer);

The range approach works better when you want to do something with your data
as if it was the converted data.

find( converter(originalData), something );
auto n = calculateChecksum( converter(originalData) );

Both are forms of conversion and each is most useful in different
situations.

Base64 encoding/decoding may be an exception, but you can describe the
process of getting the next byte/char fairly easily.

Encode: Get the next 6 bits from the input -> find char code -> yeild char
Decode: map chars to the values they represent -> get the next 8 bits ->
yeild ubyte

Converting CAN be defined in terms of getting the next piece of converted
data, and this is the only method ranges properly support.

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.
>
>
I'm quite happy with that.  It does seem like conversion functions cover the
most common case with better syntax and performance, with a loss of
flexibility.  I don't mean to argue for shunning conversion functions in
phobos, just providing equivalent ranges where we can.

What I meant earlier when I said that I think of ranges as the primary
implementation, is that I feel ranges are a closer representation of the
algorithm being used, where a conversion function represents the process of
applying the algorithm to data.  I don't mean we should tell people not to
use the conversion functions.


> Hey, I'm not dissing ranges nor your implementation. :-)  I'm just
> afraid of people making everything ranges in the first place!
>
>
Of course!
I want ranges everywhere they make sense, and would like conversion
functions where they make sense.  I just happen to believe both do in this
case!  I don't want to force the use of ranges anywhere they make code
inefficient, uglier or more complicated.

Daniel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101014/2b4c499f/attachment.html>