If this is meant to fix a bug in HTTP::Headers, it would make sense to submit this as a bugfix to HTTP::Headers or at least report the problem directly to the author. But the RT queue for HTTP-Message has no ticket from you or about this issue, so how's the author supposed to hear about it?
This is a misguided module that doesn't even do what it says it does. It only tests if a value is defined and false, not if it is actually numerically equal to 0. Also it's sloppily coded so it will issue a warning if passed undef as an argument.
This module is pointless. Installing WWW::Mechanize with a CPAN client installs it's prerequisites.
This module is pointless. Installing Moose with a CPAN client installs it's prerequisites.
Hash::Merge seems to already do this and is popular. This module doesn't even mention it, so not sure if it does anything more or better.
API for the object accessors is completely inconsistent. This might come from the webservice, but since the Perl side provides an interface, it would be smart for the author to normalize these accessor names to be more Perlish.
Don't see the point to this. It's just adding an extra object layer onto existing Perl data types.
odd module name and cumbersome api. also, Math::Combinatorics already seems to provide this functionality.
This is useless noob-ware.
If you're going to reinvent the wheel for the Nth time, you could at least document why. There's already plenty of "light" versions of Moose: Mouse, Moo, Mo, etc. Is yours faster, does it use less memory, is it more compatible with Moose.
Sort::Key blows this out of the water by several orders of magnitude (10-5000 times faster) on some of the benchmarks.
Poorly reinvented wheel with a poorly chosen name.