https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #79 from Henrik Krohns <apa...@hege.li> ---
(In reply to Michael Storz from comment #71)
> I think the whole approach of this rewording is suboptimal. I would strongly
> suggest to separate the renaming from the aliases management. The aliases
> should be managed by an extra plugin. For this, the plugin must provide two
> new commands:
> 
> add_eval_alias ALIAS SOURCE
> add_command_alias ALIAS SOURCE
> 
> Example:
> add_eval_alias check_from_in_whitelist check_from_in_welcomelist
> add_command_alias whitelist_from welcomelist_from

Thanks for the ideas, though I assume the code and inner workings of this would
get wayy to complicated for any benefits it would give. The
set_default_commands/aliases method already exists and is more than sufficient
for this purpose.

> These alias commands must be written in a central .pre file or in the
> respective .pre file of the plugin after the loadplugin statement.
> 
> This approach has a number of advantages:
> - After renaming, the plugins' code does not need to be touched.

It's no problem to touch distributed plugins. And remember that we are only
talking about backwards compatible aliases for some functions, it doesn't make
much difference when they are actually physically removed (if at all).

> - If someone would rather use allowlist/denylist or acceptlist/rejectlist
> for their rules instead of welcomelist/blocklist, they could simply set
> aliases accordingly.

Would would we want to compilicate things further by allowing people to rename
things randomly? They can do what they want with their own plugins, but what we
distribute is what they should use.

> an alias should simply be set in the symbol table:
> *check_from_in_whitelist = \&check_from_in_welcomelist;
> Then the two functions behave identically.

This was good hint and I used it, cheers.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to