The last comment was a little long, so I wanted to add some other things here...

• Why does this work?
• What's the difference between CORE::GLOBAL::Caller and CORE::Caller.
• Elaboration why one thought BEGIN was needed, and why in fact it isn't and why are things so slow when it is used?

This is just icing on the cake. Just wondering what's going on.

Thanks again, everbody!

"Why does this work?"

See CORE.

"What's the difference between CORE::GLOBAL::Caller and CORE::Caller."

The difference between CORE::GLOBAL::foo and CORE::foo is thus: The Perl built-in foo() function is "just an alias" for CORE::GLOBAL::foo(). The default implementation of CORE::GLOBAL::foo() is CORE::foo(). You can override CORE::GLOBAL::foo() (and thus the built-in foo() because that's "just an alias"), but you cannot override CORE::foo().

That's the concept anyway. The actual implementation details are far weirder. CORE:: for example is not just a package, but a part of Perl's syntax - a prefix you can add to a Perl keyword to indicate that you do not want to use an overridden CORE::GLOBAL::foo(). You cannot take references to all of the CORE:: and CORE::GLOBAL:: functions, only some of them (though each major release of Perl is improving in this regard).

"Elaboration why one thought BEGIN was needed, and why in fact it isn't"

It is necessary to have performed at least one override of CORE::GLOBAL::caller() before the line containing caller is compiled. If you're using stringy eval, then your line containing caller is probably compiled quite late.

But going back to my example:

use v5.12;

# This is basically a dummy override that must be performed early
# on so that Perl knows we'll be overriding CORE::GLOBAL::caller
# later...
#
BEGIN { *CORE::GLOBAL::caller = sub { CORE::caller(@_) } };

sub foo {
    say scalar caller;
}

sub bar {
    local *CORE::GLOBAL::caller = sub { 'xxxx' };
    foo();
}

foo();
bar();
[download]

This outputs "main" then "xxxx". Commenting out the BEGIN block, it outputs "main" then "main" - not the desired effect. (Tested on Perl 5.12.5, 5.14.3, and 5.18.0.)

"why are things so slow when it is used?"

Because after the first time an override happens, any subsequent uses of caller() get compiled into an entersub op rather than a caller op. That is, they incur the full penalty of a sub call.

Compare:

$ perl -MO=Concise -E'BEGIN { *DUMMY::GLOBAL::caller = sub {} }; calle
+r()'
4  <@> leave[1 ref] vKP/REFC ->(end)
1     <0> enter ->2
2     <;> nextstate(main 49 -e:1) v:%,{,2048 ->3
3     <0> caller[t1] v* ->4
-e syntax OK
$ perl -MO=Concise -E'BEGIN { *CORE::GLOBAL::caller = sub {} }; caller
+()'
6  <@> leave[1 ref] vKP/REFC ->(end)
1     <0> enter ->2
2     <;> nextstate(main 49 -e:1) v:%,{,2048 ->3
5     <1> entersub[t3] vKS/TARG,1 ->6
-        <1> ex-list K ->5
3           <0> pushmark s ->4
-           <1> ex-rv2cv sK ->-
4              <#> gv[*CORE::GLOBAL::caller] s ->5
-e syntax OK
[download]

use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name

CORE::caller is always the built in caller function and can't be changed. CORE::GLOBAL::caller can be changed, and if it exists will be used by a caller() call instead of CORE::caller. Note that the function to use is chosen at compile time.

This is why the BEGIN block is needed in other cases of overriding caller. Perl picks which of the functions to use for a given caller() call when compiling the code. Once it has chosen to use CORE::GLOBAL::caller, the implementation for that function can be switched out and it will use whatever is currently stored in it. In your case, caller() calls directly in evaled code will always be compiled after you set up your override. Anyone using caller indirectly, such as through Carp, would be dealing with already compiled code and it would ignore your override.

Another potential issue is that CORE::caller() has special cased behavior for when called from the DB package. Your code will cause all caller calls to be from the DB package, which means @DB::args will always be populated even when that wasn't the intent. While that doesn't break any obvious things, it is a change in semantics. The effect of this is also currently limited by the previously mentioned compilation issue.

Properly maintaining the semantics of the original function takes extra care. I would recommend looking at Sub::Uplevel. You can likely use it directly to do the frame skipping, fixing both of the above issues. If not, its code can provide guidance on what you need to do.

Thanks for the information!

Anyone using caller indirectly, such as through Carp, would be dealing with already compiled code and it would ignore your override.

Given the choice of the slowness of a global override and having someone in the debugger evaluate a Carp and get results that will probably show up in the debugger (since Carp with one level is the most common case), I'll opt for the faster different eval results. If I come accross a specific case where I am annoyed by this, I'll reassess then

Another potential issue is that CORE::caller() has special cased behavior for when called from the DB package. Your code will cause all caller calls to be from the DB package, which means @DB::args will always be populated even when that wasn't the intent. While that doesn't break any obvious things, it is a change in semantics. The effect of this is also currently limited by the previously mentioned compilation issue.

Properly maintaining the semantics of the original function takes extra care. I would recommend looking at Sub::Uplevel. You can likely use it directly to do the frame skipping, fixing both of the above issues. If not, its code can provide guidance on what you need to do.

I don't immediately see how this changes things in my case.

I looked at Sub::Uplevel. The environment and faking going on in my DB code is sufficiently complex that I don't want to introduce more stuff, and other routines adding additional fakery, unless I understand why specifically it is needed. I rely on the tests I have written and when those are insufficient, bug reports and my own experience to tell me if I think things are okay.

Unless monks (and non-monks) advise otherwise, I will take that reporting DB::DB as the calling function is a bug in Perl and create bug report for that.

It's not a bug, it's a feature. See this.

Many thanks to Dave Mitchell for going through the weeds on this.