Preamble: I'm fully aware that this may be an XY Problem and that there may well be a better approach that I should be taking; if so, feel free to suggest better approaches. However, I find the way I'm doing it now to be interesting and would still like to find the answer, even if only for the sake of curiosity.

The Immediate Question: When inserting a code reference into @INC (as described a bit more than halfway down the require docs), what should you return from your code to indicate to require that the request has been fully handled and it should not continue checking @INC in search of the file?

Based on the docs, it seems to me that return (undef, \&{sub { 0 }} ); should do the trick (second value returned is a sub reference which returns 1 for each line of source code provided and 0 at EOF), but neither this nor any of the variations on it that I've tried have convinced require that its job has been done.

The Overall Picture:

I'm in the process of redesigning a system which makes heavy use of installations being able to override the standard versions of its modules by having a lib/default for the standard version and lib/extension for the local version. Just having lib/extension first in @INC does a decent job of this, but has the drawback of requiring the lib/extension version to be a complete copy of what's in lib/default, even if only one sub needs to be overridden.

In an attempt to allow the local version to get by with only respecifying the changed subs, I've gone off and written a sub which goes at the head of @INC and, when module Foo is used/required, first loads Foo, then loads Local::Foo on top of it. This much works (aside from some warnings about redefined subroutines which no warnings 'redefine' doesn't seem to silence).

Unfortunately, after I've finished this, the normal require processing then loads module Foo a second time, reverting everything back to the non-Local version (and generating another batch of warnings, this time for every sub in Foo), which kind of defeats the purpose of the whole thing.

As for whether this should be done at all, we do plan in the redesign to add a lot more data-driven configurability and some hooks for callbacks in order to minimize the need for wholesale replacement of subs, but things are expected to vary enough from one installation to another that the capability still needs to be there.

This does sound an awful lot like OO polymorphism, and my first stab at it was based on using OOP and either constructors or factories which detect the presence of Local subclasses and return them instead of the base class, but I don't expect to see a top-to-bottom pure-OO architecture in the new version, so we'll likely need something that works with both OO and non-OO code, which is how I got started down the current path. (No pun intended.)

In reply to Telling require "I've handled it" by dsheroh

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • 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:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.