On 10.11.2009, at 20:38, Stanislav Malyshev wrote:
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 imho neither require nor include have been written with the
"right" API in mind to solve todays needs. for all i care we could
also break BC for include and adjust it according to my proposal in
PHP6.
anyways .. you are glossing over several draw backs in the current
possible approaches, each saying you can solve that in user land with
more code. yet my proposal would be a tiny change in php core
(probably alot of code could be shared) and would still surpass the
user land approaches. i do not know if there is anything possible to
make include itself more flexible since its a language construct and
not a "normal" function.
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.
ok .. so your objection to the RFC is solely because it introduces a
new language construct?
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php