Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56276
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <9274e90a58f9a9cffee6a2d9922e6ff9@mohiva.com>
References: <CAAyV7nEi+1XzYryoE9tg48jZMMPe1psz=VWDkGSzEgAwBKs9pw@mail.gmail.com>
	<CAFp73XuQGG9mEZUZ2OK1yLkBiFDcPwOxytQ80D=xZUafEv20tw@mail.gmail.com>
	<CAAyV7nG91GeszEnmhmPVVvsYp5tP3BR9aOE3QWXAQvjLFjzK+g@mail.gmail.com>
	<9274e90a58f9a9cffee6a2d9922e6ff9@mohiva.com>
Date: Fri, 11 Nov 2011 06:53:14 -0500
Message-ID: <CAAyV7nFQtUxYiLTwxygG4j+_c-W6Z2G8tpq0WWbnxHyvOwqmew@mail.gmail.com>
To: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Re: SPLClassLoader RFC Thoughts And Improvements
From: ircmaxell@gmail.com (Anthony Ferrara)

> Yes, but even in that case the autoloader would not be triggered to
> load \Foo_Bar because if you already have used \Foo\Bar previously,
> that would have loaded \Foo_Bar as well.

Well, my original point is that what if both are not defined in the
same file.  It's not that far fetched of an idea.  Let's say you're
using Zend Framework 2.  So one part of your application uses the
\Zend\Registry class. Now, let's say you import a third party library
that was built with a dependency on the ZF1 \Zend_Registry class.
Without the require_once modification, it would fatal error since both
are not in the same file (even though a later autoloader knows how to
load Zend_Registry).  Granted, it's a bit of a stretch, but it's not
out of the realm of possibility.  And considering it's trivial to
avoid the error since all it takes is require_once, I think it's worth
fixing...

> Would it not be possible that the autoloader mechanism catch all exceptions
> made by any autoloader which fails to load a class. Only if none of the
> register autoloaders can load the requested class the autoloader mechanism
> throws an AutoloadException with all the catched exceptions. This behaviour
> should be controllable by the users environment. So if using an
> autoloader(e.g. from a library) which throws an exception, but the user
> doesn't use exceptions in his environment, he should be able to deactivate
> the exceptions thrown by the autoloader mechanism. I think this behaviour
> has the greatest advantages for both worlds. This one which needs exceptions
> to shut down the application in an ordered way, and for these relying on
> PHPs way to handle the autoloading error.

Sure, it would be possible.  But that would also be a BC break.  It
may be worth it (not sure), but still.  An interesting idea...

> Not sure debug adds much here - if the class is not found, you'll be notified
> by the engine anyway, so what's the added value?

I think what he was trying to do was provide an indicator of what the
mapped file that it tried to load was.  So not throwing the exception
to show it failed, but throwing it to identify what the file path
should have been.  Not arguing if it's a significant need, just what
was intended...