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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
