text: go to bug id or search bugs for
  Description:
  ------------
  The code below works as expected on version 5.3.
  Test script:
  ---------------
  namespace Foo {
  function bar() {
  var_dump(is_callable('Foo\\time'));
  var_dump(time());
  }
  }
  namespace {
  \Foo\bar();
  eval('namespace Foo; function time() { return -1; }');
  \Foo\bar();
  }
  Expected result:
  ----------------
  bool(false)
  int(1362390237)
  bool(true)
  int(-1)
  Actual result:
  --------------
  bool(false)
  int(1362390237)
  bool(true)
  int(1362390237)
  Add a Patch
  Add a Pull Request
  confirm this change. this is due to the 5.4 performance improvement: "literal
  cache"
  @dmitry, maybe we should not cache the function entry for INIT_NS_FCALL?
  thanks
  or maybe we should document this behavior, since disable it will bring performance
  issue
  @gen the main brief is, when you first call to \Foo\Bar, the 'time' constant in
  the \Foo\Bar function, will bundle to "time function", in the first time , it
  obviously will be bundled to \time.
  then when you sencond call to it. PHP will use that cache instead of look up in
  function table again for "time" function, to increase performance..
  so, if we disable the cache, then performance slowdown...
  what do you think? a workaround is define a Foo\Bar2, after you eval, you call
  to it, then it will bundled to \Foo\Time..
  The main issue I see is that is_callabe() is lying. It says that '\Foo\bar' is callable, but in fact it's not. So just document this behavior is not enough imo, is_callabe should be tweaked to reflect actual status.
  And I don't quite understand suggested workaraund. Could you please give a simple example? In my usecase I try to mock time function to avoid sleep() calls:
  '\Foo\bar' -> '\Foo\time' in my prev comment
  I suppose the bug has to be fixed.
  The problem that the fix will slowdown each call to unqualified function from a namespace :(
  I'm not sure if we like to do it...
  The following patch has been added/updated:
  Patch Name: bug64346-2.diff
  Revision: 1365749451
  URL:
  Dmitry,
  I came across this one myself (see) and found this bugrep when I came to report it.
  I think that one-time caching as we've started to do with function look-up is an important performance feature, and something that we should look to extend -- though this is a wider discussion than this bugrep, probably a DL list discussion.
  I haven't gone through the current implementation yet, but my immediate thought is that this really just a cache-coherence issue in a cache where the invalidation rates are very low, so even if cache flushing was a relatively expensive operation, then the expected (that is average) overhead would still be small. I want to think about this some more and look at the performance issues around some approaches, before posting further -- Terry
  BTW, the title of this bug is misleading. It can still occur for *any* INCLUDE_OR_EVAL of a namespaced override of a builtin function, eg.
  namespace fred;
  some_function_which_executes_builtin();
  include "some_include_in_namespace_fred_which overrides_same_builtin();
  some_function_which_executes_builtin();
  Damn, why can't you edit your own comments :-) The include should read:
  include "some_include_in_namespace_fred_which overrides_same_builtin.php";
  of course.
  Related To: Bug #68541
  The same problem also applies to constants when accessing from a namespaced class - if the first the time the constant is accessed it is defined globally but not in the local namespace, then that global value will be used for all future accesses even if it is later defined in the local namespace.
  Since overriding global functions / constants is mostly used just for testing, could this be added as a php.ini option, like
  literal_cache_disable = 1
  Related To: Bug #63201
  Related To: Bug #74253
  Would it also be expensive to invalidate specific (not all) keys in the "literal cache" each time a function or a constant is defined?
  I'd avoid a global INI setting if possible.
  Related To: Bug #76788
  Still present in 7.3.0-beta2: