You could add a coderef to @INC, but no matter how you go about it, that will take a lot of work. First you need to implement the full handling of @INC, including coderefs that pass back filehandles and coderefs that pass back objects (then the INC method gets called). At this point there are three ways to go.
The simplest is to say that if you did not find the module, you are going to mark it as not loaded. This is sufficient for Jesse Vincent's use case.
Somewhat more complex is to add a __DIE__ handler so that if that module fails to compile you might be told about it.
The hardest is to manually try to detect whether the module successfully loaded, which would mean returning a filehandle that will track whether it was successfully read up to the end, or __END__ or __DATA__. (It is up to you whether to worry about the possibility of arriving at those tokens within strings.)
Even after all of this work, are you done? No! Because people sometimes create small helper classes within a file, and these are real. To handle those I'd suggest that any package that is found which has subroutines in it that you never saw anyone trying to load are to be considered successfully loaded. That also will cover modules that were loaded before Class::Sniff was.
I would say that the fact that overriding CORE::require doesn't override use should be documented as a bug. And I would stick with the simplest solution, which is that you only ignore modules that your coderef said were not found.
In reply to Re: How Can I Know If a Package is "Real"?
by tilly
in thread How Can I Know If a Package is "Real"?
by Ovid
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |