-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michael Parker writes: > On Sun, Jan 30, 2005 at 10:49:04PM -0800, Justin Mason wrote: > > Michael Parker writes: > > > Few things: > > > > > > 1) I thought plugin callss couldn't return values? > > > > actually -- they can. (I think in the config file case, it was the type > > of the return value changing frequently that was problematic). > > So, in the case where more than one plugin handles a call, which value > is returned? last one run wins? if any return a defined value, that is used. actually, it's ||= -- so in this case it's a little more complex because one return value supported is 0 as well as undef. hmm. it may be better to have the last plugin get the return value. > > > 2) I like the Plugin API, but why not keep the default in the code and > > > allow added plugins to override? Doesn't need it's own default > > > plugin. > > > > well, effectively doing this as a default plugin *does* this, without > > adding extra code for plugins to indicate "do not run the default > > code", which is why I did it this way. (however perhaps it doesn't > > need to be in the Mail::SpamAssassin::Plugin hierarchy, it could > > be named something else.) > > Something like: > > $foo = call_plugin > > if !defined($foo) > the default code goes here to set $foo There'd have to be an additional boolean indicating "a plugin handled this", rather than just returning undef -- since the API is tri-state (undef/0/1 as return values). > If someone disabled the plugin in init.pre and did not install their > own plugin, what would happen? no autolearning occurs, everything else works as expected. ;) - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFB/p7WMJF5cimLx9ARAkQkAJ9N5PvCCyg6mcsWq+e/L/fH9twkrgCcCuW3 CAhzpyQod68yMx2qss8S6N4= =Fph7 -----END PGP SIGNATURE-----
