The review of std.hash package

Dmitry Olshansky dmitry.olsh at gmail.com
Thu Aug 9 09:32:53 PDT 2012


On 09-Aug-12 14:15, Regan Heath wrote:
> On Thu, 09 Aug 2012 10:59:47 +0100, David Nadlinger <see at 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


More information about the Digitalmars-d mailing list