Fwd: [RFC] HashContext as Object
| From: | Sara Golemon | Date: | Fri, 30 Dec 2016 02:32:20 +0000 |
| Subject: | Fwd: [RFC] HashContext as Object | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-97492@lists.php.net to get a copy of this message | ||
On Mon, Dec 26, 2016 at 7:35 PM, Sara Golemon wrote:
> I was trawling through Pull Requests and found #660 which I think is a
> nice idea and deserves some attention. It involves minor BC however,
> so I've updated the patch and presented it for your discussing
> pleasure.
>
Specifically, I should say I'm eager to hear thoughts on the item
listed as an Open Issue.
That is: Currently hash_final() destroys the existing HashContext
resource immediately. No hope of continuing or even just reissuing
the result.
I'm quite tempted atm, to go the "copy the context, finalize to get a
digest, then restoring to the saved context state". For most use
cases of this API this is a slight overhead add since the context is
being duplicated then shortly thereafter discarded. (Bear in mind
though, that the hash_init->hash_update->hash_final API is the edge
case already compared to the all-in-one hash() and hash_hmac()
functions).
What doing this does offer, however, is a pathway to reasonable APIs
for streaming hash functions (see SHA3/Keccak Sponge Functions). As a
minor side benefit, we also get an idempotent hash_final(). So even
though there's a VERY minor BC break involved, I think it's the right
thing to do. If others agree, I'll update the diff to reflect.
-Sara