Front page | perl.perl5.porters |
Postings from February 2017
On Mon, Feb 27, 2017 at 2:56 PM, Sawyer X <xsawyerx@gmail.com> wrote: > > > On 02/27/2017 10:10 AM, Dave Mitchell wrote: >> On Sat, Feb 25, 2017 at 07:50:08PM +0100, Christian Walde wrote: >>> The point has been raised by haarg and leont that that might not be >>> entirely straight-forward due to shared code between use/require, but i >>> think in this case backwards compatibiliy should trump, even if the core >>> code looks a little more ugly as a result. >> Although I lean towards the backwards compatility camp, note that we can't >> provide *exact* backcompat even if we wanted to: the old behaviour of do() >> was strictly to search @INC, and @INC just happened often to have '.' as >> its last member. >> >> The most obvious backcompat strategy is to make 'do' always treat @INC as >> having an implicit trailing '.' when loading a 'do' file; but this will >> mean that code which explicitly removed '.' from @INC for security or >> other reasons will suddenly have 'do' loading files from locations it >> previously wouldn't have. > > This is why I believe a warning would be useful here instead. I think that loading a file as a file path rather than an @INC suffix is probably the most common use case for do, but I really don't see any reasonable way to preserve that for relative paths. Giving do an implicit trailing '.' means it can't be removed by the user, and there are certainly uses of do expecting it to search @INC. I think a warning on failure if the file exists and an @INC search was done (so not for paths starting with '/', './', or '../') is the most reasonable option here. I do wish we had something like do but with more sane semantics (die on !-e, not trap inner errors, never search @INC) but that is something to address separately.Thread Previous | Thread Next