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
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
