John Gardiner Myers <[EMAIL PROTECTED]> writes: > I think one weakness in the design of eval tests in general is that > their definition is split into two different places, a function > definition in some .pm file and a function call in some .cf file. The > .cf file isn't very amenable to multiple-line chunks of perl code, so > perhaps it would be good if the .pm files directly defined the tests.
You're getting closer to the issue, I think. Converting sections of tests into plugins where some people will want to disable the entire set due to performance, memory, or similar constraints (i.e., Bayes tests, network tests, special functionality, etc.) does make sense. However, converting individual (or nearly individual) tests that are "always on" (unless the rule gets a zero score) into plugins never has made as much sense to me. What if we allowed .cf files to include the eval test Perl code?? It's a bit more radical, but it *would* be cleaner and both adding new ones and removing old ones would be rather straightforward. Imagine, for example, the HTML-ish eval tests (some of which have been fairly stable) being located at the top of the 20_html_tests.cf file. This would give everyone, especially rule writers, a lot more flexibility. Of course, users wouldn't be able to define them. The .cf files already are code, this is just multiple-line code. > I am trying to raise my concerns in a timely manner, not waiting until > the 11th hour. Well enough. :-) Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/
