in reply to Re^4: BEGIN and compile-time
in thread BEGIN and compile-time

In this case, it doesn't matter if you add to the front or back of @INC since there's only one copy of the module.

Yes, in this case and at this time but no file system is set in stone, files get moved around and don't you just hate programs that break when files get moved around? what if one have multiple modules of the same namespace?

You're inventing problems...

Some bloke said, Programming is 1% code and 99% exception handling. I was just showing how preemptively taking the pains to avoid an exception ensures against the real problems caused by it. Prevention is far better than cure. How many users name their test packages A and B (worse still B::C), easily overseeing the fact that there's a whole array of core/public B modules at the top of the module namespace. In class inheritance, such a misfeature is propogated to child packages. On top of that, @INC is global to all scripts/modules, so your modifications to it is inherited by other code that uses yours; in multiple inheritance scenarios, @INC could be anything but what you expect and you don't want to have caused a code-avalanche for lack of a little preemption, it's always better to be safe than sorry!?!

<If .. was added to the end of @INC, your non-standard strict.pm would never get loaded, so why did you write it?

 perldoc -f use

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. For e.g. 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;
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.
BEGIN { use lib ".."; # or unshift @INC, ".." } use strict 1.04;
How about now?? no difference at all.

You still haven't addressed the problem I mentioned ..

Well ok, want proof-of-concept and the problem fully addressed?
#!/usr/bin/perl -lW # catch all bleeping errors BEGIN { push @INC, ".." } my @TAGS = qw| pedantics refs |; my $ideal_version = 1.04; eval " use strict $ideal_version @TAGS; # fails, strict's VERSION==1.03 "; if ($@ =~ /version $ideal_version required.*BEGIN failed/ism) { warn qq|use strict $ideal_version qw(@TAGS); failed, falling back|; shift @TAGS; # Unknown 'strict' tag 'pedantics' eval "use strict qw|@TAGS|"; # which strict is this?? unless ($@) { print qq|second eval, using strict $strict::VERSION qw(@TAGS) fr +om module |, $INC{"strict.pm"}; } } print qq|main now using strict $strict::VERSION qw(@TAGS) from module +|, $INC{"strict.pm"}; if ( grep /pedantics/, @TAGS ) { # newer 'pedantics' related code here # will this run under strict v1.03?? not a chance } else { # workaround for backward compat. # sub pedantics {...}; } if ( grep /refs/, @TAGS ) { # usual 'refs' related code here } else { # quite unlikely to be reached } __END__ __output__ use strict 1.04 qw(pedantics refs); failed, falling back second eval, using strict 1.03 qw(refs) from module /usr/share/perl/5. +8/strict.pm main now using strict 1.03 qw(refs) from module /usr/share/perl/5.8/st +rict.pm
As you can see, there's No function redefinition errors, no 'magic' invocation of the 'second' use; (outside of the second eval too). The 'second' use is invoked conditionally in a straight-forward, perlish try-catch construct, when and only when the first eval(use ...;) fails. The arrangement of @INC doesn't have an effect on ../strict.pm being overridden either (unless another claiming to be version 1.04 is found before it in @INC, the odds are errm, quite neglible) but again i should emphasize on pushing to @INC not the otherway.

Since both use; load the same module..

No, one's explicitly trying to load a module of a specified version, another's falling back to what use; can find, the difference is the first use; will fail if the module at a VERSION is not found, the second one loads the first available one in @INC irrespective of it's VERSION.

Furthermore, it doesn't really make sense to import raz and taz from 5.01..

In some ways it does make sense to try and import tags that might not be imported successfully at all, especially in unfamiliar territory, such as - when testing a new module out and/or you are getting a barebones operation running when a newer/standard one isn't available.

by using use; you can effectively combine something like
BEGIN { eval { require Foo::Bar; if ($Foo::Bar::VERSION eq 5.01) { import Foo::Bar qw| ... |; } }; revert() if $@; }
into simpler expressions..
eval " use Foo::Bar 5.01 qw| ... | "; revert() if $@;
I favour use; for it's advantage in compile time invocation (preemption again) as opposed to require; which is invoked at run-time, the difference is subtle yet not-so-subtle at the same time, not-so-subtle in terms of longterm keyboard wear-and-tear and premature grey hair, go figure.

Replies are listed 'Best First'.
Re^6: BEGIN and compile-time
by ikegami (Patriarch) on Nov 10, 2006 at 19:01 UTC

    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;

      >type b\Module.pm

      package Module; our $VERSION = '1.01'; 1;

      >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.

      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;

      >perl -le "BEGIN { @INC = qw( c ); } use Module 1.01; print values %INC"

      c/Module.pm

    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;

    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;

    >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.

    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.

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

      1. The require part of the use happens first
      2. The require step makes no use of the version information, just grabbing the first module of that name that it finds via @INC
      3. The version check happens second
      4. Since the version check fails, the import() part never happens
      5. 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