On 22-Jun-12 13:11, Johannes Pfau wrote:
Pull request #221 and #585 both introduce modules for a new std.hash
package. As those already change API compared to the old std.crc32 and
std.md5 modules we should probably decide on a common interface for all
std.hash modules.
These are the imho most important questions:
Free function (std.crc32) vs object(std.md5) interface
-----------------------------------------------------
I think we need a object based interface anyway as md5, sha-1 etc have
too much state to pass it around conveniently.
Yup.
Structs and templates vs. classes and interfaces
-----------------------------------------------------
It's common to use a hash in a limited scope (like functions). So
allocating on the stack is important which favors the struct approach.
That's useful especially if you use one type of hash always. (e.g. SHA-1
a-la git)
However, classes could also be allocated on the stack with scoped.
Too shitty for widespread use. +Extra indirection on each block(?).
Classes+interfaces have the benefit that we could provide different
_ABI_ compatible implementations. E.g. MD5 hashes could be implemented
with D/OpenSSL wrapper/windows crypto API and we could even add a
configure switch to phobos to choose the default implementation.
Doing the same with structs likely only gives us API compatibility, so
switching the default implementation in phobos could cause trouble.
3rd option. Provide interface/class based polymorphic wrapper on top of
structs. Come on! It's D, we can find reasonable compromise.
Basic design:
---------------
If we'll implement an object based interface (struct/class), it should
probably be an output range. Something like this:
struct/interface Hash
{
void put(const(ubyte)[] data);
void put(ubyte data);
void start(); //initialize
void reset(); //reset
ubyte[] finish(ref ubyte[] buffer = null); //See below
enum size_t hashLength; //optional? See below
}
The finish function signature is a little controversial. The length of
the result differs between hash implementations. For structs+templates
we could use static arrays, but for classes+interface we'd have to use
dynamic arrays.
toString doesn't make sense on a hash, as finish() has to be called
before a string can be generated. So a helper function could be useful.
Another open question is whether we should support 'bit hashing'.
Have a look at Piotr Szturmaj's implementation for details:
https://github.com/pszturmaj/phobos/blob/master/std/crypto/hash/base.d
--
Dmitry Olshansky
