Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46014
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Tue, 10 Nov 2009 16:41:34 -0500
Message-ID: <7D.5D.38546.D0ED9FA4@pb1.pair.com>
To: internals@lists.php.net
References: <413588E2-8AC8-49F7-B7BF-97BEFB0A71E4@pooteeweet.org>
	<bcb7aa500911100900n7c7c5dbexf5ad369134584c58@mail.gmail.com>
	<4AF9B5B8.90104@zend.com>
	<536BF944-AB9D-4B5F-86CB-B75D3C0D7F63@pooteeweet.org>
	<4AF9B9FE.1040701@zend.com>
	<40A3B652-6B6A-49C1-9481-40AA6EC7537A@pooteeweet.org>
	<4AF9C13B.4030104@zend.com>
	<32979771-1825-4D93-822D-93B27CA7262F@pooteeweet.org>
	<4AF9CD95.8080604@zend.com>
	<0440A517-342D-4E48-9936-79AB93A9BD15@pooteeweet.org>
User-Agent: Pan/0.133 (House of Butterflies)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] alternative to the fopen() hack in autoloaders
From: seza@paradoxal.org (Alban)

Le Tue, 10 Nov 2009 21:56:47 +0100, Lukas Kahwe Smith a écrit :

> On 10.11.2009, at 21:31, Stanislav Malyshev wrote:
> 
>>> ok .. so your objection to the RFC is solely because it introduces a
>>> new language construct?
>>
>> No, my objection is that it is not necessary to introduce a language
>> construct, and the construct introduced is not the right one. If
>> frameworks want to find out if file exists or get its name - we should
>> give them API to do that. If they want just to silence the errors -
>> they already have the construct to do that.
> 
> 
> They dont want to determine if a file exists. They want to be able to
> handle the case of a missing file being included differently than a
> syntax error. Since php core does not provide such features, the only
> way to do this is using the fopen() hack, iterating over the include
> path .. or I guess track errors with @. My proposal actually makes it
> possible to do what the frameworks need with less overhead. There is no
> way to do what these frameworks need inside userland without the above
> mentioned hacks. The fact that almost all frameworks are forced to use
> these hacks and quite a significant number of developers use frameworks
> (resulting in quite a number of apps end users install also using these
> frameworks) implies that we are not talking about an edge case here.
> 
> Now I also made it clear that its not about blindly silencing "errors"
> but there is a need to differentiate between different error causes. Of
> course having to use @ for such a common use case is also not ideal. Its
> just that the error handling we provide internally isnt really able to
> handle this scenario well:
> 
> 1) checking before adds overhead and opens issue with potential race
> conditions
> 2) silencing the error and using track errors adds overhead and
> potential issues with custom error handlers
> 
> Anyways, lets see if there are other comments in the coming days. I
> think you have made your priorities clear. At least I understand them,
> but do not share them.
> 
> regards,
> Lukas Kahwe Smith
> mls@pooteeweet.org

Hi,

I think if PHP throws exception instead of warning/error then this 
problem will not have existence reason : 

try
{
    include 'file';

    // if we are sure about data sort in get_included_files, just do :

    $fullFileName = array_pop(get_included_files());

    // ...
}
catch(phpParseIncludeException $e)
{
    // ...
}
catch(missingIncludeException $e)
{
    // ...
}
catch(includeException $e)
{
    // ...
}

regards,
Alban Leroux
seza@paradoxal.org