https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5965
--- Comment #5 from Mark Martinec <[EMAIL PROTECTED]> 2008-08-28 05:41:13 PST
---
(In reply to comment #4)
> broadly good, but -- I'm not fond of the side-effect change to the PMS::get()
> API. This is a public API for third party plugins and eval rules, so this
> will
> create a lot of noise when they call ->get() in the previous manner, then
> match
> against the returned value without checking for undef first.
>
> Is there some other way we can support our own internal code getting undef
> returns, without breaking backwards compat on that API? [...]
There is a better way, I had it implemented for a while but scrapped it
because calls to get() could look weird. I'll make the following change
to the tail section of a get() and appropriate changes to calls
to retain compatibility:
currently:
return (defined $found ? $found : $_[2]);
new:
# if the requested header wasn't found, we should return a default value
# as specified by the caller: if defval argument is present it represents
# a default value even if undef; if defval argument is absent a default
# value is an empty string for upwards compatibility
return (defined $found ? $found : @_ > 2 ? $_[2] : '');
so now the:
$pms->get('Subject')
becomes equivalent to:
$pms->get('Subject','')
and if one wants to receive undef for nonexistent header, the
undef needs to be specified explicitly as a second argument:
$pms->get('Subject',undef)
--
Configure bugmail:
https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
