On Wed, 08 Aug 2012 18:33:01 +0100, Christophe Travert
<trav...@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/
