Hi!
there are many approaches to caching, one of which is delete to invalidate and regenerate before the next use. again as the RFC makes it clear .. the purpose is to be able to differentiate between a syntax error and a missing file.
If you writing your own cache basing on includes, you can write sequence that handles deletion correctly, knows if your own data exist or not and doesn't need include path functions for that.
sure .. but that requires yet more code. but in that case i might as
More functionality requires more code. I think it's better than turning the language into kitchen sink of similar language constructs, each has a little tweak to suit one particular use case. Next thing we would have framework_include, database_include, template_system_include, my_personal_homepage_include and so on. I think we need to do very generic stuff in the language, less generic in functions and yet less generic - in user code.
well iterate over the include path to be able to determine the absolute path and cache that, which is something i also want to enable in an efficient manner with the optional addition of returning the file loaded instead of true in case the file does not return anything explicitly. again something that i mentioned in the RFC.
We could also have function file_find() (or any other name, let the bikeshedding begin) or something that would resolve filename against include path and return full name if such exists or false if none exists. That seems generic enough operation to have a function for.
-- 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
