|Welcome to the Monastery|
Note that the equivalent to state vars is my $_cached = ..., not our $_cached = ..., so you are really comparing apples and oranges.
Yes 'state' is more like 'my', but I disagree about apples and oranges.
I am comparing two different caching approaches:
1) caching without 'state'. old way.
2) caching with 'state'. new way.
I am comparing (2) with (1) because both about caching and (2) is much easier to write/clearer than (1). Not because 'state' (not)similar to our/my.
and my $_cached isn't much easier/clearer than our $_cached = ... (except "our" var is visible in global namespace, but I use underscore in name to indicate that it's private).
But the problem is really something else: caching a value that depends on another value without taking this dependency into account is a bug
In my example I've used $ARGV to indicate something "global" (perhaps it's not clear in that particular example that @ARGV is not something that should be passed across call stack).
Other use of global things include:
%Config variables, $^O, $$, $ENV, locale, Versions of modules used, perl version, other application specific global flags and constants, which are immutable during process execution
More than that, those global var, actually, not necessary affect the result
For example I might have a code which calculates value on 64bit machine, and a slower code which calculates it on 32bit machine. Result should be same on both. And I can assume that 32bit version will work on 64bit as well and wish to test both in unit test running on 64bit machine
does not make sense in this case.
Also, even if there is no implicit global parameter, I might want to run function twice in test with other functions mocked different ways.
There are other uses of 'state' not related to caching
Something like this untestable too
EDIT Anyway, if you suggest that function result should depend only on it's arguments, than mocking/stubbing is not needed at all. However that's not true, because we see mocking libraries exist for Perl.