No, that was deliberate. There would be no point in not using use if I did. The whole point is to defer the loading of the module until and if it is needed.

That's exactly the problem. Some of the benefits of "use"ing a module can only be observed when it is done at compile time. This is particularly important when prototypes are involved. For example, the Test::Exception module uses prototypes to allow you to use this syntax:

dies_ok {$foo->method1} 'expecting to die'; For one of my modules, I wanted to use Test::Exception in an eval so that I could skip the tests if Test::Exception was not installed. It didn't work (with the syntax shown above) until I wrapped the eval in a BEGIN block.

That's one (of an ever extending list) of reasons that I dislike both the concept and implementation, and so do not use, the Test::* suite of modules.

Test code should not itself impose additional runtime constraints and requirements. If it does, then you end up having to write testcode to test the testcode as well as the testcode to test the code under test.

Testing is good. But in my opinion, and I realise that many (most?) will disagree with me, most of the mechanisms I've seen used for performing testing of Perl, and particularly those of the Test::* suite of modules I've looked at, are too invasive and impose too many constraints, requirements and dependancies.

That's not a well-formed or properly elaborated explaination. Maybe I'll get around to thinking it through properly and writing it up one day.

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.

Test code should not itself impose additional runtime constraints and requirements.

I'm having a difficult time reconciling the notion of a library that provides additional behavior yet does not impose any additional constraints or requirements. Please do consider writing up your views more formally; I'm genuinely curious as to what you do mean.

This is getting off-topic, but I don't think Test::* imposes a heavy burden. My usual testing policy is the following:
1. Use Test::More freely. It comes with perl 5.8 and is so widely used that it is not an extravagant request by any means.
2. Optionally use other testing modules (such as Test::Pod and Test::Exception), but don't require them. Test if they are installed and skip the tests if they are not. This only requires a couple lines of code.

Another possible solution is to bundle the testing modules with your distribution. Module::Install provides a mechanism for that, and the user does not need to install any modules before or after the tests.

For one of my modules, I wanted to use Test::Exception in an eval so that I could skip the tests if Test::Exception was not installed. It didn't work (with the syntax shown above) until I wrapped the eval in a BEGIN block.

For those who don't already know, you can always call prototyped subroutines that take a bare block with () and an explicit sub {} if you want.

I've made this more explicit in the documentation of T::E for those who hate prototypes.

I overlooked that this was about conditionally loading the module somewhere between the OP and the post about HTTP::Status.

#! perl -slw

# This would normally be updated based on some condition in the code.
my $condition = 0;

# possibly very many lines of code go here

# Faking a condition in the code...
$condition ||= shift @ARGV;

if ($condition) {
  require HTTP::Status;
  import HTTP::Status;
  print RC_FORBIDDEN();  # as merlyn pointed out, we need to give the 
+parser a clue
}

__END__
P:\test>test4 0

P:\test>test4 1
403
[download]