Excellent! -- thank you. I tried testing this, but couldn't get a version mis-match to cause a compile time error.

Then I decided to get into the debugger to have a better look at what was going on -- and the debugger issued the expected error right away. I'm not sure why, but I suspect it's the difference between what stage of the preparation the Perl internals got to in each situation. The debugger gets much closer to run-time, hence it triggered the error.

Yes, the two statements run at different times, as you found out:

package November;
use base 'Juliet';    # runs at compile time
Juliet->VERSION(1.1); # runs at runtime, after November.pm has been pa
+rsed completely
[download]

This usually makes little difference as long as November.pm is its own file. If November.pm is loaded later, code from earlier modules will already have run by the time the ->VERSION() call is made.

I looked at the code for parent, which in most cases should be used instead of base. I'm wondering (since you have been involved in parent) what you think of a parent::versioned that could be invoked like this:

use parent::versioned 'Foo';       # No version checking.
use parent::versioned qw(Foo Bar); # No version checking.
use parent::versioned --norequire qw(Foo Bar); # Still no version chec
+king.
use parent::versioned ['Foo' => 0.23], ['Bar' => 1.5], 'Baz'; # Versio
+n checking on Foo and Bar.
use parent::versioned --norequire 'Baz', ['Foo' => 0.23]; # Version ch
+ecking on Foo.
[download]

Implementation would be really straightforward as a fork off of existing parent (so as not to clutter parent with baggage).

Hashrefs could be used instead, so that multiple entries could reside within a single hashref, but the array-ref keeps things nicely flat.




Dave

You could just BEGIN { Juliet->VERSION('1.1') }

This is definitely more elegant and shorter than my attempt here: Re: Using a base module with a required version.