> I don't actually see early binding as being much of a problem, the real
> problem is when the same class is both early and late bound. If you
> consistently always bind early or always bind late, opcode caches should
> be quite happy to let you do that. But if you mix the two, things get
> chaotic and the problem becomes intractable. We went through all this
> in APC a couple of years ago. My initial, somewhat naiive attempt at
i'm not sure why i can't reproduce it years ago with apc enabled and i
reproduce it with a complex script later.
a1.php
class a { function aMethod() { echo __FILE__; } }
a2.php
class a { function aMethod() { echo __FILE__; } }
child.php
class child extends a { }
main1.php which is requested first
include "a1.php";
include "child.php";
$child = new child()
$child->aMethod(); // aMethod() from a1.php, but what if i update
a1.php after child.php is cached?
main2.php which is requested later
include "a2.php";
include "child.php";
$child = new child();
$child->aMethod(); // aMethod() from a1.php because of early binding
is done before cache? or from a2.php?
with and without opcode cacher, what is echo'ed if you requests main1
first and main2 later?
with the delayed early binding, php behavior exactly the same with
opcode cachers enabled or disabled
imho, with delayed early binding, every class is binded once when
there is no opcode cacher, and opcode cacher can even decide to call
bind api before cache.
looks like we can always the delay the binding unless we want binary
back compatbility for 3rd party modules? correct me if i'm wrong
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
