Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31762
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <46CA75ED.8060506@lerdorf.com>
Date: Mon, 20 Aug 2007 22:19:41 -0700
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: Gregory Beaver <greg@chiaraquartet.net>
CC: internals Mailing List <internals@lists.php.net>
References: <46C9F217.8040804@chiaraquartet.net> <b5f7bf6c0708201306id6ae99i5bf821f9d273be85@mail.gmail.com> <46C9F50A.7040009@sci.fi> <46CA6367.9090301@lerdorf.com> <46CA71F4.40205@chiaraquartet.net>
In-Reply-To: <46CA71F4.40205@chiaraquartet.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] allowing multiple namespaces per file plus
 namespaces with brackets
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Gregory Beaver wrote:
> Rasmus Lerdorf wrote:
>> Sheez, guys, slow down a tad.  Just because he says "no performance
>> penalty" in the description, doesn't make it true.  Unless I missed
>> something in the patch, I don't see how I would resolve the symbols at
>> compile-time now which means it has been moved to the executor and in
>> doing so it implies a huge performance penalty.
> 
> Hi Rasmus,
> 
> I'm actually certain that the patch doesn't change any of the symbol
> resolution logic or add any need to move things from the compile-time to
> the executor.  This is because the namespace implementation basically
> works more like a #define macro to auto-prepend class names and function
> names with namespace names.
> 
> Old logic:
> 
> request start => CG(namespace) = NULL
> T_NAMESPACE ...;
> zend_do_namespace() => defines CG(namespace) which is used for creating
> class and function entries
> php junk
> compile end => if (CG(namespace)) destruct CG(namespace), CG(namespace)
> = NULL
> 
> New logic:
> 
> request start => CG(namespace) = NULL
> [potential php junk]
> T_NAMESPACE ... {
> zend_do_namespace() => defines CG(namespace) which is used for creating
> class and function entries
> php junk
> }
> zend_do_end_namespace() => destruct CG(namespace), CG(namespace) = NULL
> php junk (which can include class/function entries, although that's a
> terrible idea)
> T_NAMESPACE ... {
> zend_do_namespace() => defines CG(namespace) which is used for creating
> class and function entries
> php junk
> }
> zend_do_end_namespace() => destruct CG(namespace), CG(namespace) = NULL
> compile end => if (CG(namespace)) destruct CG(namespace), CG(namespace)
> = NULL
> 
> In other words, the only difference is that mid-parse the namespace
> #define-like prefix can be modified or removed.

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.

-Rasmus