On 08-Aug-12 18:16, Christophe Travert wrote:
"Chris Cain" , dans le message (digitalmars.D:174466), a écrit :
On Wednesday, 8 August 2012 at 13:38:26 UTC,
trav...@phare.normalesup.org (Christophe Travert) wrote:
I think the question is: is std.hash going to contain only
message-digest algorithm, or could it also contain other hash
functions?
I think there is enough room in a package to have both
message-digest
algorithm and other kinds of hash functions.
Even if that were the case, I'd say they should be kept separate.
Cryptographic hash functions serve extremely different purposes
from regular hash functions. There is no reason they should be
categorized the same.
They should not be categorized the same. I don't expect a regular hash
function to pass the isDigest predicate. But they have many
similarities, which explains they are all called hash functions. There
is enough room in a package to put several related concepts!
You still can use say crc32 as normal hash function for some binary
object. The notions are not as desperate as some designers would want
them to be.
Here, we have a package for 4 files, with a total number of line that is
about one third of the single std.algorithm file (which is probably too
big, I conceed). There aren't hundreds of message-digest functions to
add here.
I'd rather see clean by family separation, as importing one huge digest
module only to use SHA is kind of creepy. On the other hand as all of
code is templated it's not a big deal.
If it where me, I would have the presently reviewed module std.hash.hash
be called std.hash.digest, and leave room here for regular hash
functions. In any case, I think regular hash HAVE to be in a std.hash
module or package, because people looking for a regular hash function
will look here first.
I thing concerns me: if incremental digest hashes are all in one module
what are the (would be) other modules in std.hash?
--
Dmitry Olshansky
