Skip Menu |

This queue is for tickets about the Digest-SHA CPAN distribution.

Report information
The Basics
Id: 95487
Status: resolved
Priority: 0/
Queue: Digest-SHA

People
Owner: Nobody in particular
Requestors: KENTNL [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 5.90
Fixed in: 5.91



Subject: No longer subclasses Digest::base

I'm not sure how bug worthy this is really.

I have code that takes a variable field, and I have a Moose type constraint that simply asserts that the variable ->isa('Digest::base')  so I can assume it works as intended, and so the user can pass any digest object they desire.

However, now it no longer inherits Digest::base,  Digest::SHA no longer *appears* to be compatible to my type check.
 

It could be my type checking is wrong to begin with, not sure.

Fortunately its not in a critical code path for me, and its not documented to end users that this can be replaced, and its hidden in a private attribute, so I can probably afford to change that without much fallout.

Just not sure that would be the right approach.

You are correct that Digest::SHA, as of version 5.90, no longer subclasses Digest::base. The decision not to subclass was deliberate and appears to remove no essential functionality. For that reason I'm rejecting this ticket. As pointed out in the Digest::base documentation, implementations of other digest modules *might* want to inherit from the base class to get ready-made versions of the 'addfile', 'hexdigest', and 'b64digest' methods. Since I now provide optimized versions of all those methods in Digest::SHA, there's no longer a need to subclass. Rather than type-checking objects at run time, it's always possible just to perform the intended operation in an 'eval' block, and then to catch any exceptions via $@. But if you can come up with further reasons to subclass from Digest::base, I'll certainly take them under advisement. Thanks for your input. Mark
Version 5.91 once again subclasses from Digest::base.