Russ Allbery wrote: > 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. >
That was sort of what I did on the patchset I submitted. Except for the tear-up part. t/scripts/Lintian/Checks/intro.pm represents the ideal use. Or am I missing something? the eval() calls need to be replaced as you suggested of course. Glad the old mbox was archived. Back in May I rewrote some parts of the branch to avoid creating the objects and calling run() directly. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
