Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46012
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error)
Mime-Version: 1.0 (Apple Message framework v1076)
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
In-Reply-To: <4AF9CD95.8080604@zend.com>
Date: Tue, 10 Nov 2009 21:56:47 +0100
Cc: Guilherme Blanco <guilhermeblanco@gmail.com>,
 PHP Developers Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: 7bit
Message-ID: <0440A517-342D-4E48-9936-79AB93A9BD15@pooteeweet.org>
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>
To: Stanislav Malyshev <stas@zend.com>
Subject: Re: [PHP-DEV] alternative to the fopen() hack in autoloaders
From: mls@pooteeweet.org (Lukas Kahwe Smith)


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