Re^3: RFC: feature proposal re code in @INC

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

Comment on Re^3: RFC: feature proposal re code in @INC

Replies are listed 'Best First'.
Re^4: RFC: feature proposal re code in @INC by blazar (Canon) on Jan 26, 2006 at 18:36 UTC
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...	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: RFC: feature proposal re code in @INC
by blazar (Canon) on Jan 26, 2006 at 18:36 UTC

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

[reply]
[d/l]
[select]