use Perl

• On the Test::Builder::Tester lynch mob (Score:2)

  by 2shortplanks (968) on 2005.10.11 9:52 (#43819) Homepage Journal

  I believe that in times like these, one is supposed to say: You are wicked and wrong to have broken inside and peeked at the implementation and then relied upon it.

  Let me say that the so-called 'screen-scraping' idea for T::B::T was entirely the author of Test::Builder's idea [perl.org] and uses only documented interfaces. There is no 'breaking inside' or 'peeking' going on. If you can think of any better way to determine if the diagnostics that are output from your new testing module matches what you expected to output than capturing the output and comparing it, then I'd like to hear it.

  I suppose the moral of the story is that if you write a module that has a another module as a prerequisite, you should make sure you are aware of all changes made to the prerequisite, whether it be by watching new beta uploads (or writing a program to do the watching for you), or subscribing to the right mailing list or something else. Doubly so if you're walking around with a shot-gun in the lounge, or whatever the saying is. Nothing is ever carved in stone.

  Or I could not bother releasing software to CPAN in the first place at all - you're asking module authors to do a *lot* of work here. There's no automatic mechanism provided as a way to notify me if a new beta version of a module is uploaded. Quite frankly I don't have time to read all the Perl mailing lists for every single prerequisite of every module I have uploaded. Who does? And as for writing a tool to do automatic monitoring, it's a nice idea, but completely impractical and not at all core to what I'm trying to do - which is develop the software I'm trying to develop not spend time writing tools that monitors the current contents of CPAN.

  It's the expectation that I should jump right then and there because someone else has released something that's broken a third party's code that I find annoying. It's neither really my problem or a problem of my making. I'm willing to take the time 'fix' my modules because I like to think of myself as a nice guy, but unless people are prepared to realise that Perl developers have their own priorities (or at least, their employer's) then there's going to continue to be a lot of ruffled feathers.

  Maybe I'm not up to maintaining a CPAN module. Maybe I'll not bother uploading modules in the future to avoid the grief.

  Excuse me while I pick up all my toys and put them back in the pram.

  Reply to This

  • Re:On the Test::Builder::Tester lynch mob (Score:2)

    by schwern (1528)

      I believe that in times like these, one is supposed to say: You are wicked
      and wrong to have broken inside and peeked at the implementation and then
      relied upon it.
     
    Let me say that the so-called 'screen-scraping' idea for T::B::T was entirely the author of Test::Builder's idea [perl.org] and uses only documented interfaces.

    The method of grabbing the screen output is documented, but exactly what gets output is not. The way I put it was:
    
    You are wicked and wrong to have scraped the
    • Re:On the Test::Builder::Tester lynch mob (Score:2)

      by 2shortplanks (968)

      How could so many people miss such a widespread failure? What can be done to fix that?

      Let's face facts, we're busy, busy people. Rafael's point about monitoring releases (particularly beta ones) is a good one. I should have been doing that. But it's very hard - I don't have time to read the perl-qa list every week, and it's sometimes months between when I blast though each of my mailing lists. Why don't we look at what steps can be taken to make it easier to monitor what releases are coming out?

      I li