Patch for opcode caches

-----Original Message-----
From: Xuefer [mailto:xuefer@gmail.com]
Sent: Saturday, March 15, 2008 11:21 AM
To: Rasmus Lerdorf
Cc: Marcus Boerger; Stas Malyshev; Dmitry Stogov; Andi
Gutmans; internals@lists.php.net
Subject: Re: [PHP-DEV] Patch for opcode caches

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

Compatibility is not an issue for php-5.3.
We don't need to delay early-binding without opcode caches.
It will do exactly the same as current early binding but slower.

Thanks. Dmitry.