Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:15815
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <4252A6D0.7070005@php.net>
Date: Tue, 05 Apr 2005 10:55:12 -0400
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Marcus Boerger <mail@marcus-boerger.de>
Cc: Andrey Hristov <php@hristov.com>,
	Stanislav Malyshev <stas@zend.com>, internals@lists.php.net
References: <5.1.0.14.2.20050403125628.03f83de0@localhost>	<425002D8.50004@php.net> <Pine.LNX.4.58.0504041644200.27375@shire.zend.office>	<42515CFC.2050108@php.net> <Pine.LNX.4.58.0504041859510.7207@shire.zend.office>	<42516F85.10803@hristov.com> <425181BF.4090403@php.net> <1325222760.20050405054311@marcus-boerger.de>
In-Reply-To: <1325222760.20050405054311@marcus-boerger.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: __autoload() enhancement
From: cellog@php.net (Greg Beaver)

Marcus Boerger wrote:
> Hello Greg,
> 
> Monday, April 4, 2005, 2:04:47 PM, you wrote:
> 
> 
>>Andrey Hristov wrote:
>>
>>> Stanislav,
>>>Greg probable means something like a stack trace of the autload callbacks
>>>that were called. This will be a nice addition just like Exception 
>>>stacktraces
>>>are (I wish there were stacktraces for Fatal errors).
> 
> 
>>yes, a stack trace would be ideal - I knew there was a name for that 
>>thing I was describing :)
> 
> 
> A stack trace is only some additional information that has no real added
> information. Also it is not a real stack trace since what you asked is
> just a list of functions called at one level and not the trace up to
> that part where a class was missing (which would be a stack trace).

I imagined that a failed __autoload() would leave the old on one the 
call stack, as if the user had inserted the call to the new __autoload() 
before the last closing }.

> After my last commit you can get a stack trace by throwing an exception
> in the last called function. To get a list of all functions being called
> just check spl_autoload_functions().

The exception solution will only work if the user puts a throw() in 
there.  The list of functions would be more useful, imo.

> A combination of both would require the engine to be changed to be capable
> of handling multiple exceptions - which hopefully we do not want. Right
> now a second exception while an exception is already pending results in a
> fatal error.

I don't think putting exceptions into __autoload is a good idea at all, 
the only use exceptions serve is to bubble out of contexts, whereas an 
undefined class will simply error out.  Simpler is to provide an option 
for users to define an error handler that can display the __autoload() 
functions used with some kind of listing function, whether it is 
spl_autoload_functions() or an engine feature.

Greg