Re^6: BEGIN and compile-time

You're completely missing the point of using the VERSION directive with use; to locate and load a precise module irrespective of it's location within @INC.

That's completely wrong for the following two reasons:

use Module VERSION loads the first module in @INC, regardless of it's version.
>type a\Module.pm
```
package Module;
our $VERSION = '1.00';
1;
[download]
```
>type b\Module.pm
```
package Module;
our $VERSION = '1.01';
1;
[download]
```
>perl -e "BEGIN { @INC = qw( a b ); } use Module 1.01;"
```
Module version 1.01 required--this is only version 1.00 at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
[download]
```
It works this way because Perl doesn't know what the module will store in $VERSION until the module has run.
use Module VERSION will successfully load a module whose version is greater than VERSION. A precise match is NOT needed.
>type c\Module.pm
```
package Module;
our $VERSION = '1.02';
1;
[download]
```
>perl -le "BEGIN { @INC = qw( c ); } use Module 1.01; print values %INC"
```
c/Module.pm
[download]
```

Nowhere does it say that use or require will attempt to locate a module of the correct version. Furthermore, the Perl equivalent of these functions is included in the documentation, and there's no such functionality in it.

The standard strict.pm is now around version 1.03; if my very own ../strict.pm is at version 1.04 and i used this..
BEGIN { push @INC, ".." }
use strict 1.04;
[download]
what do you think a subsequent strict->VERSION() or $strict::VERSION would report?? Note where ".." is placed in @INC. There's no two ways around this, 1.04 it is as ../strict.pm is loaded.

For the reasons explained above, that's wrong.

>type d\strict.pm

package strict;
our $VERSION = '1.04';
1;
[download]

>perl -e "BEGIN { push @INC, 'd' } use strict 1.04; print strict->VERSION"

strict version 1.04 required--this is only version 1.01 at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
[download]

I favour use; for it's advantage in compile time invocation (preemption again) as opposed to require; which is invoked at run-time,

All else being equal, eval "use Module VERSION"; and require Module; ... execute at exactly the same time.

But all else isn't equal here. Your use is executed at "run-time" (since the eval is executed at "run-time") and my require is executed at "compile-time" (since it's in a BEGIN block).

Well ok, want proof-of-concept and the problem fully addressed?

This still has problems. Given your misunderstandings about the fundementals of execution order and of use Module VERSION, and given your lack of willingness to listen (I already posted a working solution and you're not asking for advice), I don't feel like outlining the problems with this code.

Note: All tests have been run in Perl 5.6.1, 5.8.0 and 5.8.8 with similar results.

Comment on Re^6: BEGIN and compile-time Select or Download Code

Replies are listed 'Best First'.
Re^7: BEGIN and compile-time (version) by tye (Sage) on Nov 10, 2006 at 19:17 UTC
To be slightly clearer on a couple of points, when `use Module VERSION` fails because the version number is not high enough The `require` part of the `use` happens first The `require` step makes no use of the version information, just grabbing the first module of that name that it finds via @INC The version check happens second Since the version check fails, the `import()` part never happens The successful `require` doesn't get undone BTW, some modules are smart enough to provide their own `sub VERSION` so that they can record which version was requested and then have that information impact their `sub import` to cause it to act in a backward-compatible manner. That way they can make more types of improvements in newer versions of their module without breaking backward compatibility (so long as they documented that users of their modules should always specify which version's interface they programmed to). - tye	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^7: BEGIN and compile-time (version)
by tye (Sage) on Nov 10, 2006 at 19:17 UTC

To be slightly clearer on a couple of points, when use Module VERSION fails because the version number is not high enough

The require part of the use happens first
The require step makes no use of the version information, just grabbing the first module of that name that it finds via @INC
The version check happens second
Since the version check fails, the import() part never happens
The successful require doesn't get undone

BTW, some modules are smart enough to provide their own sub VERSION so that they can record which version was requested and then have that information impact their sub import to cause it to act in a backward-compatible manner. That way they can make more types of improvements in newer versions of their module without breaking backward compatibility (so long as they documented that users of their modules should always specify which version's interface they programmed to).

- tye

[reply]
[d/l]
[select]