On 09-Aug-12 14:15, Regan Heath wrote:
On Thu, 09 Aug 2012 10:59:47 +0100, David Nadlinger <s...@klickverbot.at>
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.
struct ShaState
{
...
alias ubyte[16] getDidgest();
}
Problem is: too much magic, spoils auto x = reduce(...); idiom.
To be brutally honest I don't see what in std.hash doesn't fit "range
component" model:
- it works on input ranges via convenient adaptor (or would work soon)
- it has output _ranges_.
What's not to like about it? That it doesn't fit general reduce
algorithm? I'm not convinced it's important. In the same vane you may
try to shoehorn symmetric cyphers to follow map interface because
conceptually it does 1:1 conversion.
Now important thing: just look at other output ranges.
They either require extra call (see Appender .data) or horrendously slow
and ugly see lockingTextWriter/Reader.
--
Dmitry Olshansky
