Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31763
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.114 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 20 Aug 2007 22:31:00 -0700
Message-ID: <698DE66518E7CA45812BD18E807866CE92D7D5@us-ex1.zend.net>
Thread-Topic: [PHP-DEV] [PATCH] allowing multiple namespaces per file plus namespaces with brackets
Thread-Index: AcfjsxGGwoXMGPQATHSUZ8OkNbCjwwAAUy8w
References: <46C9F217.8040804@chiaraquartet.net> <b5f7bf6c0708201306id6ae99i5bf821f9d273be85@mail.gmail.com> <46C9F50A.7040009@sci.fi> <46CA6367.9090301@lerdorf.com> <46CA71F4.40205@chiaraquartet.net> <46CA75ED.8060506@lerdorf.com>
To: "Rasmus Lerdorf" <rasmus@lerdorf.com>,
	"Gregory Beaver" <greg@chiaraquartet.net>
Cc: "internals Mailing List" <internals@lists.php.net>
Subject: RE: [PHP-DEV] [PATCH] allowing multiple namespaces per file plus namespaces with brackets
From: andi@zend.com ("Andi Gutmans")

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
>=20
> 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 =3D> CG(namespace) =3D NULL
> > T_NAMESPACE ...;
> > zend_do_namespace() =3D> defines CG(namespace) which is used for
> creating
> > class and function entries
> > php junk
> > compile end =3D> if (CG(namespace)) destruct CG(namespace),
> CG(namespace)
> > =3D NULL
> >
> > New logic:
> >
> > request start =3D> CG(namespace) =3D NULL
> > [potential php junk]
> > T_NAMESPACE ... {
> > zend_do_namespace() =3D> defines CG(namespace) which is used for
> creating
> > class and function entries
> > php junk
> > }
> > zend_do_end_namespace() =3D> destruct CG(namespace), CG(namespace) =
=3D
> NULL
> > php junk (which can include class/function entries, although that's
a
> > terrible idea)
> > T_NAMESPACE ... {
> > zend_do_namespace() =3D> defines CG(namespace) which is used for
> creating
> > class and function entries
> > php junk
> > }
> > zend_do_end_namespace() =3D> destruct CG(namespace), CG(namespace) =
=3D
> NULL
> > compile end =3D> if (CG(namespace)) destruct CG(namespace),
> CG(namespace)
> > =3D NULL
> >
> > In other words, the only difference is that mid-parse the namespace
> > #define-like prefix can be modified or removed.
>=20
> 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.
>=20
> And nested namespaces really make a mess of this if something like
this
> is allowed:
>=20
> foo.inc:
> namespace A {
>   include 'bar.inc';
> }
>=20
>=20
> bar.inc:
> namespace B {
>   ...
> }
>=20
> 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.
>=20
> -Rasmus
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php