http://bugzilla.spamassassin.org/show_bug.cgi?id=3711
------- Additional Comments From [EMAIL PROTECTED] 2004-08-22 14:18 ------- Sorry Malte -- I'm very -1 on the idea of a read_scoreonly_config() name change. it's purely a matter of naming. The semantics aren't changing, so renaming would be just to make the code "look nicer". That's not a good thing at all for public APIs. Consider the UNIX creat(2) system call -- Ken Thompson is quoted as saying if he could change anything in UNIX, he would call this function "create" rather than "creat". But nobody has ever renamed it in 30 years, because it's a documented, *public* API, and to do so would be to *force* callers to change their code -- for no good reason! ;) Also consider the setuid(2) system call -- that's been around for years, has wildly differing semantics, and a whole batch of additional APIs (seteuid, setreuid, setresuid, etc.) to work around it's wierdness. But nobody's done away with setuid() -- they've just added newer, sane ones. Making people change their code by changing the Mail::SpamAssassin perl APIs is something we really have to avoid. It's not good practice, and fundamentally, half of SpamAssassin's purpose is as a library of perl modules with public APIs -- that's why it's on CPAN. read_scoreonly_config() is one of those public APIs that's been around for the entire lifetime of the project. And doing it at this stage -- right before 3.0.0 release -- would be terrible timing; we'd be forcing all the third-party developers who use Mail::SpamAssassin, like amavisd, MailScanner et al, to have to scramble to put out new releases to cope with the change. (We've already given them plenty of heads-up on the Mail::SpamAssassin::Message change and I think they're all up-to-date on supporting that in their products by now.) However... I'd be +1 on changing the POD docs to reflect more correctly what that API *does*. (as you say, it also allows users to set some options.) And changing the backend private API names is no problem, where they are not intended to be called directly by users. load_scoreonly_sql() and load_scoreonly_ldap() as far as I know are purely private methods. ditto parse_scores_only() and read_cf(). We can change these at any time, but changing them *now* is a bad idea until we've got 3.0.0 out the door (finally!) We *could* add a parallel API that's more sane, although in this case I think it'd be unwarranted -- all we'd be doing is adding an exact duplicate under a different name, since *what the call does* wouldn't be changing. lastly: agreed that we should adopt a convention for private APIs, and the "leading underscore" one is perfect for this; commonly-used, familiar to most people, already used in parts of our code, sensible, short. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
