Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:32592
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Wed, 3 Oct 2007 16:52:09 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <1449632176.20071003165209@marcus-boerger.de>
To: Greg Beaver <greg@chiaraquartet.net>
CC: internals Mailing List <internals@lists.php.net>, 
	johannes Schlueter <johannes@php.net>
In-Reply-To: <47029B22.4010205@chiaraquartet.net>
References: <4701D607.7010405@chiaraquartet.net> <1411108822.20071002112931@marcus-boerger.de> <47029B22.4010205@chiaraquartet.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] link to exceptions in autoload thread?
From: helly@php.net (Marcus Boerger)

Hello Greg,

Tuesday, October 2, 2007, 9:25:22 PM, you wrote:

> Marcus Boerger wrote:
>> Hello Gregory,
>> 
>>   I don't recall any particular thread but Andi once explained why a few
>> things are instable when exceptions are pending. Some of that is no longer
>> the case so maybe it is time to reinvestigate the whole issue of pending
>> exceptions. But maybe that would result in an exception stack like in Java
>> and I am not sure whether I would not simply favor our current bahavior.

> Hi,

> I actually don't mind the current behavior, although it would be nice if
> instead of an E_ERROR it simply displayed the exception as if it were
> uncaught (ignoring the exception handler - just shunt and display as an
> Exception would).  Even this is not a big issue, I've been using die(new
> Exception(...)) and it does the same thing.

> What I was wondering is to understand __autoload()s internals a little
> better.  Your message plus my investigation of the source leads me to
> ask a pre-patch question:

> I'd like to avoid my little fatal error trick if the user simply called
> class_exists('Classname', true) and same for interface_exists().  If I
> provide a simple patch that would introduce a new HashTable of
> classnames into EG() called EG(in_class_exists), and a new userspace
> function in_class_exists() that returns true if __autoload() was called
> by class_exists(), would that be an acceptable addition into PHP 5.3?

In theory class_exists() should simply return false if __autoload() cannot
find it. Why make that more complex? Is it avoiding the time to load and
compile the class? If so wouldn't normal code that checks for a class being
avaiable later use that class?

Check:
php -r 'function __autoload($c) { echo "Autoload: $c\n";} var_dump(class_exists("bla");'

You can even do class_exists($class_name, false) to avoid the call to to
__autoload().

> This way, my autoload handler could simply return if the user is
> querying the existence of a class, and die pre-emptively with the
> exception I want in other cases where an E_ERROR would result.

> This feature would be extremely useful for PEAR2's implementation of
> autoload.  Currently, I check the stack frame of the exception for
> class_exists() prior to die()ing with it, which is risky at best, and a
> performance hog.

> Thanks,
> Greg



Best regards,
 Marcus