Excerpts from William Morgan's message of Thu Oct 01 10:07:20 -0700 2009: > I like the idea, but how about a hook instead? I think the reply-mode > hook is exactly equivalent to this. (Which maybe I will one day rename > to default-reply-mode.) > > I have a strong aversion to adding configuration options.
I'm intrigued. What makes a hook preferable over a configuration option? I've been getting concerned watching the number of hooks in sup grow as each creates a maintenance burden. Either: 1. All hooks are supported forever with consistent arguments/semantics, (which may make it more difficult to make changes in sup than it would be otherwise) OR: 2. Hooks are not supported forever, in which case users may find that things just start working when upgrading. Neither of those seem options look nice to me, and both seem easy to avoid with configuration options. If the plan is to go with (1) I'm concerned that I don't see sup shipping documentation for the current possible hooks. (This applies to configuration options too though. I think the maintainer should reject patches that add either without also adding documentation to the standard list.[*]) [*] Assuming the pre-condition of such documentation existing of course. On the other hand, I also dislike configuration options (and hooks, equally), to the extent that they might be used as an excuse to avoid putting the most sane and useful default functionality into sup itself. Obviously, this can be complicated by some people not agreeing on what the most sane and useful behavior is. -Carl
signature.asc
Description: PGP signature
_______________________________________________ sup-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/sup-talk
