Re: Restructuring check scripts
Raphael Geissert <geissert@debian.org> 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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: