On Thu, 09 Aug 2012 10:59:47 +0100, David Nadlinger <s...@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/
