The review of std.hash package

Regan Heath regan at netmail.co.nz
Wed Aug 8 10:41:29 PDT 2012


On Wed, 08 Aug 2012 18:33:01 +0100, Christophe Travert  
<travert at phare.normalesup.org> wrote:

> "Chris Cain" , dans le message (digitalmars.D:174477), a écrit :
>
> I think you misunderstood me (and it's probably my fault, since I don't
> know much of hash functions), I was wanted to compare two kind of
> concepts:
>
> 1/ message digest functions, like md5, or sha1, used on large files,
> which is what is covered by this std.hash proposal.
> 2/ small hash function. Like what are use in an associative array, and
> are called toHash when used a member function.
>
> And I didn't thought of:
> 3/ cryptographic hash functions
>
> My opinion was that in a module or package called hash, I expect tools
> concerning #2. But #1 and #2 can coexist in the same package. The
> proposed std.hash.hash defines a digest concept for #1. That's why I
> would rather have it named std.hash.digest, leaving room in the hash
> package to other concepts, like small hash functions that can be used in
> associative arrays (#2).
>
> I don't know the difference between #1 and #3, so I can't tell if they
> should share a common package. In anycase, I think putting #3 be in a
> crypto package makes sense.
>
> Having 3 different packages seems too much to me. #1 is too
> restricted to be a whole package IMHO, and should be along #2 or #3.

Here is a perfect example of why we need to avoid using "hash", it has too  
many meanings to different people.

I suggest:

std.digest <- cryptographic "hash" algorithms
std.crc    <- crc "hash" algorithms
std.uuid   <- identity "hash" algorithms

This is assuming we cannot have more levels of depth in the package/module  
tree, otherwise you could group them all under the package "hash":

std.hash.digest
std.hash.crc
std.hash.uuid

Some people are going to argue it should be:

std.crypto.digest or..
std.crypto.hash

But that leads us to something like:

std.crypto.hash
std.crc.hash
std.uuid.hash

And that seems back-to-front to me, and more importantly would  
assume/suggest/require we have more packages to put in std.crc and  
std.uuid, which I suspect we wont.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/


More information about the Digitalmars-d mailing list