Front page | perl.perl5.porters |
Postings from August 2012
On Wed, Aug 1, 2012 at 5:00 PM, Jesse Luehrs <doy@tozt.net> wrote: > On the smoke-me/require branch: > > $ ./perl -e'require ::tmp::foo' > Can't locate tmp/foo.pm in @INC (@INC contains: /home/doy/perl5/local/ /usr/local/lib/perl5/site_perl/5.17.3/x86_64-linux /usr/local/lib/perl5/site_perl/5.17.3 /usr/local/lib/perl5/5.17.3/x86_64-linux /usr/local/lib/perl5/5.17.3 .) at -e line 1. > > $ ./perl -e'require ::::tmp::foo' > Bareword in require maps to disallowed filename "/tmp/foo.pm" at -e line 1. > > So how is the goal not accomplished? I don't quite understand the point > you're trying to make with those code snippets. I hadn't tested the branch, but your example reinforces my answer to Nicholas about consistency of require. I think the right answer is to have any number of leading "::" give the second error above. (Though I would bikeshed the error message itself into something more useful. s/disallowed/disallowed absolute/ perhaps.) For the purpose of hardening Perl and shipping 5.16.1, I suppose the fix in that branch is tolerable, but then making the two consistent the way I believe they should would be *another* behavior change after 5.16.1, which is sort of sucky. Imagine if after 5.16.1 someone starts relying on "::foo" mapping to a relative path in @INC in production code. Do we need a deprecation cycle to change that behavior? ;-) -- DavidThread Previous | Thread Next