Raphael Geissert <[email protected]> writes: > Russ Allbery wrote:
>> 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. Yeah, I think I'm just slow. :) Or I wasn't paying attention to your explanation the first time around. It makes a lot more sense now. Sorry about that! For some reason, I didn't think about data shared between checks. Hm, if we're going to make use of that, we should also ensure that the checks are called in a predictable order or can declare dependencies on each other or something... although I suppose they could use a separate sub to gather the data and use the same technique that Lintian::Collect uses to cache it. > 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. Yeah, I don't think you're missing anything. > 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. I am sorry it's taken me so long to respond! I'll try not to disappear like that again. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
