http://bugzilla.spamassassin.org/show_bug.cgi?id=3715
------- Additional Comments From [EMAIL PROTECTED] 2004-08-23 12:20 -------
'Because the return value, currently, can be anything, not just a number.
For instance, the hash_key return value is either a key=>value pair or
a number (for invalid/missing). Some things return undef, some things return
strings, etc.'
and treating it as a number when it could be a string results in horrible
warnings when "use strict" is on. annoying...
'> 2. I guess this one falls under "big API change for which its too late" ;)
But
> I don't like the fact that the success return value for the $cmd->{code}s is
> obviously undef. That should be either 1 or something like $VALID_VALUE (==
> 1); maybe <=0 -> error and >=1 -> success.
Yeah, I was thinking about that as I went through for the first patch.
Hence my comment above the code call. It should be a bit better defined,
but yeah, that'll be 3.1 I think. It requires modifying large chunks
of code in Conf/Conf::Parser to return numbers only and not undef
anywhere....'
the success return value could be anything. it's only the failure cases that we
need to care about.
this was explicit (although I should document it ;). I'll do that post-checkin
as a doc change.
reason why: there's lots of those 'code' subs, and adding "boilerplate" items to
them, like a required "return 1" line in each one, will just increase code size,
make it more annoying to write those subs, cause errors when people forget that,
and generally cause pain. dealing with error return codes can be done more
easily in one place (Parser) rather than in 100 places (each of the code subs).
I'm not sure I like it --
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
