Rasmus Lerdorf wrote:
> Right, which breaks the single-namespace per file rule. Opcode caches
> work on a per-file basis, so I know for a single op_array that I will
> never have to worry about a secondary namespace lookup because I know up
> front which namespace I am in. By allowing multiple namespaces per file
> I have to keep checking or do some other clever trick to figure it out.
>
> And nested namespaces really make a mess of this if something like this
> is allowed:
>
> foo.inc:
> namespace A {
> include 'bar.inc';
> }
>
>
> bar.inc:
> namespace B {
> ...
> }
>
> In this case bar.inc's functions will either be A::B::func() or
> B::func() depending on how it is included which again means I can't do
> any compile-time optimization.
Hi Rasmus,
The patch explicitly disallows nested namespaces, the result of your
sample above will be two separate namespaces, global and B. Also, the
namespace processing is still per-file, it just adds a bit more
complexity within a file for APC and company. I didn't realize you were
talking about an opcode cache when speaking of moving things to the
executor, but I still think by essentially implementing this as macro
expansion, you can convert the two files to:
foo.inc:
include 'bar.inc';
bar.inc:
class B::Whatever {...}
and in other files, resolve imports in the same manner:
another.inc:
include 'bar.inc';
import B::Whatever;
$a = new Whatever;
becomes:
another.inc:
include 'bar.inc';
$a = new B::Whatever;
What else is there here that I'm missing? I was under the impression
that all of the namespacing tricks (as implemented) are determinate
aliases to class names and function names that contain "::" in the
actual CG() hash tables.
I don't wish to cause trouble on these points, but I don't yet
understand how the patch makes things any worse for APC, as all of the
namespacing is still 100% deterministic and is a closed per-file system
done at compile-time.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
