The review of std.hash package

[Walter Bright]

On 8/9/2012 2:59 AM, David Nadlinger 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.

It is not a meaningless statement in that components have a predictable set of 
methods and properties. That's all a range is. Requiring extra methods means 
there's either an error in the component interface design or an error in the 
component instance design.

What I'm trying to get away from is the C library style where every library 
lives in its own world, and when the user tries to connect them he's got a fair 
amount of work to do building a scaffolding between them.

With component programming, the interfaces between disparate things is 
standardized. It does not have unique methods for different instances. For 
example, one component has a finish() method, another has a getResult() method, 
and a third has no method at all. This situation I wish to avoid.


>> 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.

Wouldn't that be simply the handle to the hash?

> 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.

I understand what finish() does. The interesting part is trying to figure a way 
out of needing that method. Or perhaps the reduce component design is incorrect.