Gregory Beaver wrote:
> 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:
Well, outside of an opcode cache, you wouldn't care whether the logic is
in the compiler or the executor. But once you introduce an opcode
cache, anything that you can resolve at compile-time means one less
thing to do at execute time which means that the feature essentially
becomes free once the file has been compiled and cached.
Current opcode caches, including APC, will replace class and function
definitions with NOPs in the cached op_arrays when it can definitively
resolve them at compile-time. Things like autoload and conditional
includes are examples of features that destroy this optimization because
we need the runtime context in order to determine what to do which means
we have to do it in the executor. Then of course there is the nightmare
of class inheritance spanning includes and code that sometimes includes
a file containing a child class conditionally and other times
unconditionally. That caused us weeks, if not months, of headache in
APC land.
> 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.
Perhaps it doesn't. What worries me is the ability to change the
namespace mid-file. Maybe I can resolve this entirely at compile-time
as long as no includes, imports or any other tricks can be used to break
the namespace-to-one-file association. And we especially have to avoid
anything that would cause a single file to change namespaces depending
on how it is included and where it is included from.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
