Re^3: Silencing specific warnings when executing coderef? (caller)

Dunno if caller is somehow safely overwritable

Don't join the too-many developers who have made the mistake of trying to replace caller so that they can hide their magic even more. Code behavior should never depend on caller (that is putting the dependency in the wrong order, despite it being a common trick when loading package-impacting modules like Exporter). So caller should be for debugging on some level.

The last thing I want is to be lied to when I'm trying to debug a problem (a task that is often complicated already). So modules that overload caller are simply unacceptable to me.

- tye

Comment on Re^3: Silencing specific warnings when executing coderef? (caller)

Replies are listed 'Best First'.
Re^4: Silencing specific warnings when executing coderef? (caller) by LanX (Saint) on Mar 23, 2014 at 19:27 UTC
I agree mostly, thats what I meant with "it's tolerable for a functional construct not to be too transparent.". I don't wanna run against windows while running. But I might offer such an import option for the case that someone really needs to overwrite it. Anyway `caller()` has after all a clumsy interface (indexed list), something like `xcaller()` returning a (blessed) hash could handle both cases. Cheers Rolf ( addicted to the Perl Programming Language)	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: Silencing specific warnings when executing coderef? (caller)
by LanX (Saint) on Mar 23, 2014 at 19:27 UTC

it's tolerable for a functional construct not to be too transparent.

But I might offer such an import option for the case that someone really needs to overwrite it.

Anyway caller() has after all a clumsy interface (indexed list), something like xcaller() returning a (blessed) hash could handle both cases.

Cheers Rolf

( addicted to the Perl Programming Language)

[reply]
[d/l]
[select]