Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:32623
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 38.99.98.18 cause and error)
Message-ID: <47042302.8000008@chiaraquartet.net>
Date: Wed, 03 Oct 2007 18:17:22 -0500
User-Agent: Thunderbird 1.5.0.13 (X11/20070824)
MIME-Version: 1.0
To: Stanislav Malyshev <stas@zend.com>
CC: internals Mailing List <internals@lists.php.net>
References: <470334FE.7050808@chiaraquartet.net> <47040F7A.6050207@zend.com>
In-Reply-To: <47040F7A.6050207@zend.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] in_class_exists() for detecting __autoload()
 called by class_exists() and interface_exists()
From: greg@chiaraquartet.net (Gregory Beaver)

Stanislav Malyshev wrote:
>> to use die() or some other method of terminating execution.  A user
>> calling class_exists() clearly expects a return from autoload, whereas a
>> user instantiating an object will expect a fatal error if the class
>> cannot be found.
>
> This is true, but __autoload should never do it, the engine should do
> it. So I think it's better just not make autoloader *ever* produce
> errors. Can't find it - just give up, if engine really needs it it'd
> bail out :)
Another possibility: could there be a way to add context information (a
string) to the error message the engine displays?  This would alleviate
my concern.
>> This is useful for PEAR2 as a means of displaying helpful information on
>> locating missing class files only in cases where a fatal error would
>> result anyways.
>
> Well, autoloader might print debug traces etc. if the developer wants
> it, but I don't see why this should be unique feature for class_exists.

the point is that if the user is using class_exists() they don't want
extra output on missing class.

Greg