Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46033
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error)
Mime-Version: 1.0 (Apple Message framework v1076)
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
In-Reply-To: <4AFC1B5B.3080503@smashlabs.com>
Date: Thu, 12 Nov 2009 16:41:28 +0100
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: 7bit
Message-ID: <41BF743A-7A86-482F-A7A7-8C05A5DC2A21@pooteeweet.org>
References: <413588E2-8AC8-49F7-B7BF-97BEFB0A71E4@pooteeweet.org> <4AFC1B5B.3080503@smashlabs.com>
To: Ralph Schindler <ralph@smashlabs.com>
Subject: Re: [PHP-DEV] alternative to the fopen() hack in autoloaders
From: mls@pooteeweet.org (Lukas Kahwe Smith)


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
mls@pooteeweet.org