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.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.