OK, I'll bite.
I admit I was trolling (I was going to wait until it was fixed and
then mention " 0"), but I do have a point I'm actually trying to
prove.
The talk that is actually relevant to this is Matt's Catching an ::Std:
http://www.shadowcat.co.uk/archive/conference-video/yapc-na-2009/std/
Basically many of your modules revolve around invented standards which
are not only mostly irrelevant to actual development, they often
contain simply incorrect interpretations.
ZeroButTrue is such an example. Perl already has two builtin
standards, making this confusing enough. The norm is:
# this is always safe:
if ( defined( my $number = could_return_zero() ) ) {
but then "0 but true" is hard coded to numify as 0 to make the return
values of certain builtins be true when the result is valid but equals
zero, allowing people to say:
if ( my $number = could_return_zero() )
Unfortunately this is not used universally, even in Perl's own
builtins (for instance the index() function returns -1 on failure, and
many other builtins return undef, simply returning 0 even if that's a
valid value (e.g. pos, fork, etc etc)).
DBI introduced a second, related but dissimilar hack, exploiting the
fact that arbitrary floating point expressions numify to zero, but
numification is not used to make "0" be treated as false, that's a
hard coded behavior.
Your modules attempts to be consistent, that is become a standard,
supporting DBI's convention of "0E0" and perl's builtin "0 but true",
but in fact there are many other standards such as "0.0", " 0".
The actual check for 0 but true behavior should be ( $value && $value
== 0 ) but you are inventing a standard whereby only the two common
strings are supported.
"0 but true" in its own right is a pretty bad idea, but further
compounding it by using a flakey is_zero_but_true test that won't work
on all values found in the wild, and encouraging the adoption of that
as a consistent standard is harmful to CPAN, the community, and people
learning Perl. Your target audience for this module is people who are
already confused by 0 but true behavior, and therefore are seeking
something simple and consistent, and though your module claims to do
that it falls short.
Many of your other modules exhibit similar problems:
Data::Rand before 0.0.3 made false claims about the security, and
still has problematic random value distribution.
all.pm needlessly complicates the loading of modules.
fake.pm will only work for a very small subset of modules (namely
pragmas that fiddle %^H)
HTML::Obliterate reinvents HTML parsing in regexes and gets it wrong
("< script" could still be dangerous if more scrubbing is done later,
and won't be cleaned up, the entity handling is wrong (entities are
stripped instead of being converted to plain text)),
DBIx::Std claims to invent a standard but doesn't even provide that
UNIVERSAL::cant injects code into UNIVERSAL, seemingly extending the
already questionable standard that is the UNIVERSAL namespace, for
something that is really uncommon and can be implemented by typing '!'
before the method call.
Sub::Todo promotes goto $sub and sets $! for no real reason ($!
corresponds to the C level errno api, not internal errors). ENOSYS
means the POSIX api function is not implemented, and has a very
different meaning. Furthermore, hardcoding magic numbers in the Perl
source code corresponding to the various platforms' arbitrary header
files just to support this incorrect usage of that error number is
even worse.
Mail::Sender::Easy attempts to reinvent Mail::Message::Builder or the
plethora of Email:: modules, all of which are ambitious projects that
*still* don't get it right a lot of the time. Some of the things this
gets wrong is e.g. encoding of non trivial content disposition
filenames. That requires a *lot* of code to get right, and the fact
that this module is smaller, doesn't make it easier to use than many
of the other more stable offerrings.
In short, my problem is that you tend to reinvent perfectly round
wheels, and then ship them to the CPAN in what appears to be an
attempt to get the Perl community to standardize on that.
I think that's harmful to the CPAN and the Perl community in general.
Personally I also find it hard to believe that you really use these
modules extensively without getting burned. Perhaps it's easier for
you because you know what to expect, many of these modules have many
flaws and wrong assumptions that seem to imply that they weren't
really thought through.
