Re: RFC: feature proposal re code in @INC

[diotalevi]

Try this. It does something but I'm not sure what.

@_ = ( $_[0], "Whatever.pm" );

PS, if you change the value from read-only, you'll probably be modifying the optree. That's usually a bad idea.

[blazar]

I'm not sure if I understand your proposal, which is probable, given your hacking skills. However I don't want to force $_[1] to hold "Whatever.pm" for use in the same sub - I want it to be modified as a side-effect of the sub having been called, and I don't want to change the value from read-only either: I "want" it not to be read-only in the first place.

I was thinking of something along these lines: suppose that one writes some modules in different versions for some different OSen (OK: as I premised since the beginning, I know there are other ways to do this), well if she had this feature available then she may do something like:

use lib sub {
    for (qw/Foo.pm Bar.pm Baz.pm/) {
        if ($_[1] eq $_) {
            $_[1] =~ s/\./-$^O./;
            last;
        }
    }
    # let perl go on searching the 'faked' .pm!
    undef;
};

(There are probably better examples.)

I admit that this opens an ambiguity as to what should be shown in case the modified module can't be found: is it, say, Foo.pm or Foo-linux.pm that can't be found? Probably, both, I would say: the error message may report both the original name and the "current" (at failure time) one, if they differ.

[Tanktalus]

I can imagine that someone could come up with a good way to use this feature. For example, in chaining with other code refs. I'm not entirely sure how that would work, but someone might be able to get it to work.

However, I'm pretty sure this particular example would breed nothing but headache and heartache - there is no fallback mechanism here to allow you to say that if Foo-linux.pm doesn't exist, Foo.pm will be fine. Or, if it isn't fine, to print out a usable error message. Because as the user, I'd probably be confused by any error message referencing "Foo-linux.pm" when I had a "use Foo" in my code without some sort of extra information on my screen.

Instead, I would suggest that code that is intended to stack probably should be made into objects that have an INC method (see require). Someone may write a generic "extract from tarball" INC object. If you want to change the name you get from the tarball, you can write your own INC object that wraps the tarball INC object, and changes the name on the way through.

(Note that before looking this up during the writing of this node, I wasn't even aware of INC objects...)

[blazar]

I was aware of the INC object. Well, just because to be sure every now and again I check perldoc -f require, although in fact I usually stick with the "sub form of code-in-@INC". Now, indeed this kind of hackery is there for doing stuff like "extracting from tarball" (or retrieving over a network connection, maybe). In this case, if I "only" want to change a filename, or a relative path (e.g. Foo/*.pm to Foo-devel/*.pm) as shown in my previous example, then I may search regular @INC directories for the real file I want and return an open file handle to it. But that would amount to reinventing the wheel. And it wouldn't chain with other code in @INC. I may just want perl to do that for me instead...

Indeed agree that some care should be payed to a fallback mechanism and to informative error messages. But modulo these caveats, after all this is a somewhat advanced hackery and fundamentally adding the feature would amount to... removing a feature, precisely the one that makes the passed path read-only, so...

[diotalevi]

Gawds. Use some mundane magic for once. This @INC hackery sucks when used for things like this. Instead of "crecent wrench" you're pulling out the "hyper-spacial quantum vortex thingie with extra nubbly attachment." I loathe your example.

BEGIN { eval "use Foo-$^O; 1" or die $@; }