Re: Restructuring check scripts
Russ Allbery wrote:
> Raphael Geissert writes:
>> Russ Allbery wrote:
>
>>> More that you can get rid of the object completely and just do the
>>> direct sub calls that the run method was doing, I think (although it's
>>> been a while since the thread, and I should have responded right away
>>> so that I remember what I was thinking).
>
>> Ah, you mean to treat them like static methods?
>
> 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.
>
>> Do you know how Test::Class works?
>> I don't fully understand how the 'sub name : Something' part is
>> implemented. A similar approach could be used in Lintian, to make the
>> code even more flexible and easier to understand.
>
> I don't -- I've never looked at it. It's one of those things that showed
> up after I stopped closely tracking Perl development, so I'm a little bit
> behind the times on things like annotations.
Ok. Maybe we could take a look at it on the next refactoring phase.
>
>>> Also, whenever there are problems, it's a lot easier to track them down
>>> if the tests are run in the same order for us as they are for the
>>> person reporting a problem.
>
>> 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 :)
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Reply to: