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?
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
I just showed you at least two different ways to do it, with different APIs. You may not agree it's right APIs but please don't make it appear as your solution is only possible one in existence. It is not.
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.
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.
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? There's a reason why language constructs tend to be primitive - because you can assemble a lot of use cases from simple primitives, but it's hard to deal with use-case-tailored constructs. We have four inclusion constructs in language as it is, I think it's enough.
-- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
