Diddling @INC, order of entries in it

[Rafael Garcia-Suarez]

On 01/08/07, David Cantrell <david at cantrell.org.uk> wrote:
> > In other words, if 'prototype "CORE::do"' returns undef, you cannot
> > override do.
> >   ~ $ perl -MData::Dumper -le 'print Dumper prototype "CORE::do"'
> >   $VAR1 = undef;
> >
> > However, aliasing it to an overridden CORE::GLOBAL::Require seems to
> > work:
> >
> > What have I misunderstood?  Is this a bug?
>
> Given that 'prototype' says that 'require' isn't over-rideable, then it
> sure looks like one, and so I'm not going to do it because now that it's
> been found some bugger will go and fix it.

Someone called for me ?

Anyway, no fix yet, but an explanation :

The overriding of require() is treated specially.

And why is it treated specially, would you ask ? That's pretty evil --
because in some cases the optree checker rewrites its arguments. Like,
changing "Foo::Bar" in "Foo/Bar.pm". That ensures afterwards that the
function you provided to replace require gets "Foo/Bar.pm" and not
"Foo::Bar".