develooper Front page | perl.perl5.porters | Postings from July 2008

Re: [RFC] Dual-lifing

Thread Previous | Thread Next
Nicholas Clark
July 1, 2008 01:53
Re: [RFC] Dual-lifing
Message ID:
On Mon, Jun 30, 2008 at 12:54:29PM -0400, Jerry D. Hedden wrote:
> Jerry D. Hedden wrote:
> > From what I can tell, there are well over a dozen dual-lived
> > modules that incorporate into their distributions.
> > Rather than continuing this trend, I would like to propose
> > turning it into a module and dual-lifing it to CPAN.
> Nicholas Clark wrote:
> > Why are they using it, rather than something built from
> > Test::Builder?  What does it offer that Test::Builder
> > derived modules don't?
> Jerry D. Hedden wrote:
> > In my case of dual-lifing threads, threads::shared,
> > Thread::Queue and Thread::Semaphore, it was because the
> > tests were already written to use  Thus, adding it
> > to the distribution was easier than rewriting all the tests.

But, logically, those tests in the modules in core can be re-written to
not use it [if, see below]

> > I would imagine that is also the case for the other
> > dual-lived modules that use, but their maintainers
> > could have other reasons.  Anybody?
> Additionally, has certain functionality (e.g.,
> fresh_perl() and watchdog()) not found in the Test::*
> modules.

hence I think that a better solution would be to add just that code to a
Test::Builder based module, either a new one, or an existing one if its
maintainer is keen.

The core's is meant to be a subset of the Test::More functionality
for core regression tests in t/* (distinct from tests in lib/* for modules
shipped with core). To me it feels like scope creep if it also ends up dual-
lived. It also means that we would have *two* core-supported test frameworks,
which can't be used in the same test.

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About