std.hash design

[Dmitry Olshansky]

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