Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31761
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:07:24 -0700
Message-ID: <698DE66518E7CA45812BD18E807866CE92D7CD@us-ex1.zend.net>
Thread-Topic: [PHP-DEV] [PATCH] allowing multiple namespaces per file plus namespaces with brackets
Thread-Index: AcfjsHQNkXmwfbnhRwmzwXxMcoTe1AAAKmjQ
References: <46C9F217.8040804@chiaraquartet.net> <b5f7bf6c0708201306id6ae99i5bf821f9d273be85@mail.gmail.com> <46C9F50A.7040009@sci.fi> <46CA6367.9090301@lerdorf.com> <46CA71F4.40205@chiaraquartet.net>
To: "Gregory Beaver" <greg@chiaraquartet.net>,
	"Rasmus Lerdorf" <rasmus@lerdorf.com>
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")

Greg,

Will review your patch...
Thanks,

Andi

> -----Original Message-----
> From: Gregory Beaver [mailto:greg@chiaraquartet.net]
> Sent: Monday, August 20, 2007 10:03 PM
> To: Rasmus Lerdorf
> Cc: internals Mailing List
> Subject: Re: [PHP-DEV] [PATCH] allowing multiple namespaces per file
> plus namespaces with brackets
>=20
> 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.
>=20
> Hi Rasmus,
>=20
> 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.
>=20
> Old logic:
>=20
> 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
>=20
> New logic:
>=20
> 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
>=20
> In other words, the only difference is that mid-parse the namespace
> #define-like prefix can be modified or removed.
>=20
> Greg
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php