On Sun, Sep 25, 2005 at 07:53:40PM -0400, Randy W. Sims wrote:
> I haven't tried overriding yet, but your mention of a change in
> internals reminds me of another approach I had tried without success.
> The docs imply in its psuedo perl version of C<require> that I might be
> able to set $INC{'Foo.pm'} to undef or some false value to cause require
> to fail. It does not under 5.8; I haven't tried under other versions
> yet. Is that part of the behavior that changed while the docs didn't? or
> did I misread something?
The change I remember is that perl now does the bareword -> filename
translation for you so that: require Foo; calls CORE::GLOBAL::require
in 5.6 with "Foo" and "Foo.pm" in 5.8. This was necessary because its
nearly impossible for the CORE::GLOBAL::require() routine to distinguish
between 'require Foo' (meaning require "Foo.pm") and 'require "Foo"'.
I've now discovered that in 5.8 Perl ignores the "CORE" part of a
CORE::require call instead trying to be all smart and deciding for you
whether to call CORE::require or CORE::GLOBAL::require based on whether
you're inside a CORE::GLOBAL::require call causing all sorts of interesting
bugs. This is not only broken behavior but the decision logic is so dumb
that it only looks at the immediate caller so things like:
*CORE::GLOBAL::require = sub {
return _my_require($_[0]);
};
sub _my_require { CORE::require($_[0]) }
goes into infinite recursion because Perl thinks its smarter than you and
calls CORE::GLOBAL::require instead of CORE::require inside _my_require.
Its been perlbug'd.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Stabbing you in the face for your own good.
