Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46016
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: <4AF9DAEC.3050504@zend.com>
Date: Tue, 10 Nov 2009 23:10:37 +0100
Cc: Guilherme Blanco <guilhermeblanco@gmail.com>,
 PHP Developers Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: 7bit
Message-ID: <FBCF8B10-E54C-486A-B1CF-A3B117852897@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> <0440A517-342D-4E48-9936-79AB93A9BD15@pooteeweet.org> <4AF9DAEC.3050504@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 22:28, Stanislav Malyshev wrote:

> Hi!
>
>> 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
>
> Let's see why they need to handle missing file being included  
> differently? Or, even more interestingly - why they need to include  
> file that is missing if they know they'd have to do something  
> different? Maybe they would want to know if file exists or nor  
> before trying to include it, because they don't know which exactly  
> file they are going to include?
> The goal here, at least for ZF, is to find the right file and  
> include it. Both APIs that I proposed allow to express it directly -  
> find file and include it. Your API would make them do it through  
> chain of trial and error by trying to include a string of non- 
> existing files before actually trying a successful one, thus mixing  
> three functions - finding files, including files and error reporting  
> - into one. How it's better?

Because its tons more efficient, requires less code from the end user  
and all the various other reasons i have stated before. Again we seem  
to have different priorities but reiterating them doesnt provide value  
for this mailinglist. So your points are taken, I will add them to the  
RFC. We will see if other people have an opinion and then someone  
might call for a vote.

>> 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
>
> How you are going to differentiate? Your proposal only has one  
> return value (null) which is conveniently coincides with return  
> value that can be produced by include too by doing return;.  You  
> don't know why it failed, you don't even really know did it fail or  
> not. You just know you got null in return.

I stated the differences to include. As such I did not state that  
syntax errors should be handled differently, so in the case of a  
syntax error false would be returned and a warning raised.

>> 1) checking before adds overhead and opens issue with potential  
>> race conditions
>
> I don't think it's real use case - please show me one framework that  
> uses plugin includes through include path while other processes are  
> deleting their plugins randomly. I think you are trying to solve non- 
> existing problem here. Caching/templating APIs usually know exactly  
> where their files are and don't need to look for them in include path.

I never claimed that the race condition is a common scenario. Do note  
that I always called this an edge case, both on this list an in the  
RFC. The performance overhead however is real, both from additional  
function calls as well as additional filesystem access.

>> 2) silencing the error and using track errors adds overhead and  
>> potential issues with custom error handlers
>
> Again, what frameworks need is to find the right file among variety  
> of possibilities in include path and then include it. I think it can  
> be well served by using existing "include" with addition of "find"  
> API and there's no necessity for new language construct to serve one  
> specific use case. In a month, some framework would have slightly  
> different use case and you'd invent another packaged language  
> construct for this?


You are repeating yourself in the same email. You are not addressing  
2) so just leave it out on your reply.
To address your comment about if I am going to invent another  
construct. I have as well as other framework developers brought up  
this limitation in PHP for a while. You might have also noticed that  
this construct aka hack has been around for a while. So I am not  
trying to patch up the issues I discovered yesterday, I am trying to  
find a solution for a problem that has been know since years. As a  
result I do not share your concern that tomorrow we will need yet  
another different "magic" method to handle includes.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org