On 12.11.2009, at 15:27, Ralph Schindler wrote:
There is one key piece of information to keep in mind about this
proposal. This is based on the assumption that all autoloaders need
to do this type of include_path check. I (now) feel this is
questionable concerning that particular use case.
The best practice should be to only have autoloaders for a specific
namespace, this would mostly solve the "is it there?" type of fopen/
include_path check.
If NamespaceA registers an autoloader for itself, it should not try
to resolve and load files from other Namespaces, for example
NamespaceB. This idea is partially taken care of in the proposed
SplClassLoader ..
http://gist.github.com/221634
.. assuming the above best practice, a namespcae should know whether
or not to try to include something inside it's own namespace, and if
something is not there, an E_FATAL (or potentially an exception) is
the best option when include does not work. I also have a question
as to how the argument: throw=true comes into play in the current
spl_autoload_register (does it affect this proposal too?)
http://github.com/php/php-src/blob/PHP_5_3_1/ext/spl/php_spl.c#L422
ON THE OTHER HAND, I think it is important that we should be able to
check for the existence of a relative to include_path location
regardless of autoloading consequences, and that is what sara
attempted with stream_resolve_include_path, even though I'm not fond
of the name.
your argument has some merit, however i think that the use case should
still be supported.
well even inside your own namespace it can be tricky to know the file
name. for example in MDB2 i allowed the creation of modules. these
could either be generic or rdbms dependent. since i did not want to
have to maintain some registry that knows all modules (especially
since modules can be added by users), i had to search for the right
class name by seeing which file was available (either a directory with
the module name and rdbms drivers as the php files .. or a generic php
file). there might be other similar use cases, like having to deal
with legacy code.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
