Raphael Geissert <[email protected]> writes: > Russ Allbery wrote:
>> Yeah. There really isn't an object, currently, underneath any of the >> checks. We could make each check its own object, but I'm not sure >> we're gaining anything by doing so compared to just making available to >> it the objects that it might need as parameters. > I was thinking about the different methods sharing common information > collected at runtime. Now that I think about it, it might be more > appropriate to add support for some sort of "tear up" and "tear down" > methods in case we find some use for it. Oh, hm, yes. That's not a bad idea. In that case, what if we made each check a first-class module, with use base, and then for each check we can then call the constructor, providing a default one and allowing the test to override if it needs to do setup. Then the standard Perl DESTROY method can handle tear-down if one is needed. Oh, and then run can be an object method, and the default implementation can be to use introspection to find all check_* methods and run each of them. Then, all we have to do is modify the existing check scripts to ignore the first argument to run, and they keep working as-is, but we can rewrite them to use check_* methods at our leisure. >>> Of course :) (unless there's a --predictable option ;-) >> Yeah, we could do it that way. :) I would expect the sort to be a >> fairly small part of the running time, though. > I was joking actually :) Oh, okay. :) -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
