On Sun, 10 Oct 2010 19:20:00 +0900, Daniel Murphy <[email protected]>
wrote:
On Sun, Oct 10, 2010 at 5:06 PM, Masahiro Nakagawa
<[email protected]>wrote:
What do you think?
Masahiro
So the only reason to re-write it was to change the license?
License is the most important thing.
1. License issue
2. RFC version is 2045
3. Supporting format is MIME only
Some suggestions:
(API)
1. Convert the whole thing to a range based design.
ubyte[] <-> dchar range
I read Andrei's reply, OK.
2. Accept ubyte[] or void[] as well as string
I will change encode and decode signatures.
string encode(in string) -> string encode(in void[])
string decode(in string) -> ubyte[] decode(in string)
3. Add a constant for no padding
maybe
enum NoPadding = '\0';
I think
alias Base64!('!', '=', Base64.NoPadding);
is a lot clearer and easier to use.
Good! I will add NoPadding.
4. Rename Base64Impl to Base64 and add default arguments for the standard
character/padding settings.
template Foo(char A1 = 'a')
{
void func() { writeln(A1); }
}
Foo.func() // Compilation Error!
Foo!().func() // OK
Right?
(Style)
5. Reduce use of *ptr++ style code in favour of foreach/ranges etc.
6. Use assumeUnique instead of casting arrays to immutable.
I think the entire thing should be @safe unless REALLY needed for speed.
My first implementation doesn't use pointer, but such implementation is
slow :(
I think Base64 needs speed(encode and decode are often called in some
application).
assumeUnique isn't pure function...
Hope I've been helpful.
Daniel.
Thanks for the review :)
Masahiro
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
