<div class="gmail_quote">On Thu, Oct 14, 2010 at 4:59 AM, Masahiro Nakagawa <span dir="ltr"><<a href="mailto:repeatedly@gmail.com" target="_blank">repeatedly@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>I wait no-caching implementation. I think Range should not have useless state.</div>
In addition, current implementation seems to be still more complex than necessary.<div><br><br></div></blockquote><div> </div><div>I thought you might say that.</div><div><a href="http://yebblies.com/rangebase64nocache.d" target="_blank">http://yebblies.com/rangebase64nocache.d</a></div>
<div>These ranges only read the bits that they actually need off the input, only converting one output item per popFront. I don't consider this a better solution. I haven't adapted length to work with this version, but I will if this implementation is actually going to be used.</div>
<div><br></div><div> I'd welcome any ideas/suggestions on how to simplify the implementation of either version, especially the Decoder length, which is considerably ugly.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br></div>
I don't think so. Range is a good concept, but not all.<br>
I think usability is a most important factor for module API.<div><br><br></div><div>
<br></div>
Base64's API is following:<br>
<br>
encodeLength(length);<br>
encode(src, dst);<br>
encode(src);<br>
encoder(returns Encoder!(char[]) or Encoder!(char))<br>
decodeLength(length);<br>
decode(src, dst);<br>
decode(src);<br>
decoder(returns Decoder!(ubyte[]) or Decoder!(ubyte))<br>
<br>
Do you see any problems?<br><font color="#888888">
<font color="#000000"><font color="#888888"><br></font></font></font></blockquote><div>Looks fine to me.</div>
</div>