RE: [PHP-DEV] [PATCH] allowing multiple namespaces per file plus namespaces with brackets

Yep, we need to still review in detail but if it messes up the rules Rasmus has pointed out then it's a real issue. I think this is actually the reason why we didn't support it in our proposal. Andi > -----Original Message----- > From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com] > Sent: Monday, August 20, 2007 10:20 PM > To: Gregory Beaver > Cc: internals Mailing List > Subject: Re: [PHP-DEV] [PATCH] allowing multiple namespaces per file > plus namespaces with brackets > > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php