[phobos] std.base64 replacement

[Masahiro Nakagawa]

On Wed, 13 Oct 2010 19:03:41 +0900, Daniel Murphy <yebblies at gmail.com>  
wrote:

> On Wed, Oct 13, 2010 at 4:47 PM, Shin Fujishiro <rsinfu 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.

I wait no-caching implementation. I think Range should not have useless  
state.
In addition, current implementation seems to be still more complex than  
necessary.

>> I don't see much benefit to make filters decorator ranges in the first
>> place.  You can implement them, but decorator ranges should be
>> considered extensions to core filters implemented as Masahiro's way.
>>
>> So, I believe that Masahiro's encode(src,sink) design wins.  His base64
>> filter has a control over the number of bytes to process, and hence no
>> need for extra caching.
>>
>> Of course, decorator ranges are useful in some situation, and we'll
>> eventually need them.  But they should never supersede Masahiro's
>> filters.
>>
>>
> I don't see any real differences between the lazy range design and the
> conversion function design, apart from the usual lazy vs eager factors of
> performance, memory consumption and interface simplicity.
>
> I tend to see the lazy solution as the primary solution, and the  
> conversion
> function as an alternative implementation optimized for speed and/or
> usability.
> One similar example is std.string.split vs std.algorithm.splitter.

I don't think so. Range is a good concept, but not all.
I think usability is a most important factor for module API.

> That being said, I think we do need both, as the conversion function  
> should
> be more efficient and simpler to use for the most common case (buffer ->
> buffer).

I agree.

> I'd hate to have to use
>   copy(Base64.decode(inputbuffer), outputbuffer);
> over
>   Base64.decode(inputbuffer, outputbuffer);
> just as I'd never want to write
>   copy(repeat(5), buffer);
> over
>   fill(buffer, 5);

Base64's API is following:

   encodeLength(length);
   encode(src, dst);
   encode(src);
   encoder(returns Encoder!(char[]) or Encoder!(char))
   decodeLength(length);
   decode(src, dst);
   decode(src);
   decoder(returns Decoder!(ubyte[]) or Decoder!(ubyte))

Do you see any problems?


Masahiro