The review of std.hash package

[Regan Heath]

On Thu, 09 Aug 2012 10:59:47 +0100, David Nadlinger <see at klickverbot.at>  
wrote:

> On Wednesday, 8 August 2012 at 19:27:54 UTC, Walter Bright wrote:
>> The idea is to have hash act like a component - not with special added  
>> code the user has to write.
>
> Sorry, but I think this is a meaningless statement without specifying  
> what kind of interface the component should adhere to. In my opinion,  
> the proposed std.hash design would be a perfectly valid interface for  
> »accumulate stuff and at some point get a result«-type components.
>
>> In this case, it needs to work like a reduce algorithm, because it is a  
>> reduce algorithm. Need to find a way to make this work.
>
> Hash functions are _not_ analogous to reduce(), because the operation  
> performed by reduce() is stateless, whereas hash functions generally  
> have some internal state.
>
> »Continuing« a reduce() operation by repeatedly calling it with the last  
> partial result as the starting value is only possible because there is  
> no additional state to carry over. To make this work with hashes, you'd  
> have to return something encapsulating the internal state from your hash  
> function.

This isn't necessarily a problem.

> But then, you again need to obtain the actual result from that return  
> value from that result somehow, which defeats the original intent of  
> making it work like reduce – and incidentally is what finish() does.

But, this is a problem.  finish in most cases pads the remaining data to a  
boundary of the internal state size, then completes one more iteration of  
the algorithm to produce the final result.

So, like David has just said, you can have 1 or the other.  Either you can  
chain hashreduce operations together, but you have to perform a manual  
finish step to get the actual result, or you cannot chain hashreduce  
operations together and finish is done automatically when the input range  
is consumed.

Wild thought.. and I have to admit I've not followed the proposed or  
suggested API closely, nor have I used ranges extensively so this may not  
be possible..

If the range/hash object stores the current state and returns this as the  
result of hashreduce, it would be chainable.  If it also had a "Digest"  
property/method which performed finish on a /temporary copy/ of the state  
it would almost be as automatic as reduce.  There would still be a manual  
step to get the result, but it would be analogous to calling toString on  
any range object to output it's "value".  The Digest property/method would  
not modify the internal state, and could be called at any time between  
(not sure there is a point to this) or after chained hashreduce operations.

R

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