Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33980
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain webfactory.de from 195.227.108.51 cause and error)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 12 Dec 2007 21:39:04 +0100
Message-ID: <00A2E2156BEE8446A81C8881AE117F199A076A@companyweb>
Thread-Topic: AW: AW: [PHP-DEV] Namespace resolution
Thread-Index: Acg86BSbTvY/95IDTKGeVsDE4CeSgQAFiTgw
To: "Stanislav Malyshev" <stas@zend.com>
Cc: =?iso-8859-1?Q?David_Z=FClke?= <dz@bitxtender.com>,
	<internals@lists.php.net>
Subject: RE: AW: AW: [PHP-DEV] Namespace resolution
From: mp@webfactory.de ("Matthias Pigulla")



> > Just a quick idea - what if requiring that autoloaders behave=20
> > deterministically, that is, once a certain autoloader=20
> > implementation=20
> > has been given the possibility to find a class it will=20
> > never be asked=20
> > again (because it wouldn't find it later on either).
>=20
> I'm not sure if it's a correct assumption to make in general case -=20
> files can be created.

Currently, when an autoload handler is given the chance to load a class =
and it does not, maybe another handler will do. Either way, the script =
will terminate if no handler can find the class or the class will be =
available after that - so already now it is impossible that any given =
handler is called twice during the same execution for the same class =
name.

Maybe I'm missing some weird cases for opcode caches or otherwise =
embedded PHP though?

-mp.