Russ Allbery wrote: > Raphael Geissert 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.
I probably wasn't clear enough back when I made the proposal. No worries. > > 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. That's why I suggested turning Lintian::Collect into the canonical data interface. By moving all the data collecting logic into a separate module it will be easier to later support multiple threads (which I hope at some point we do) as the locking mechanism would be needed there and not on every check. >> 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. > Np. No matter how hard we try there are time we simply can't get to work on something ;-). 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]
