Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46007
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: <4AF9C13B.4030104@zend.com>
Date: Tue, 10 Nov 2009 20:48:46 +0100
Cc: Guilherme Blanco <guilhermeblanco@gmail.com>,
 PHP Developers Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: 7bit
Message-ID: <32979771-1825-4D93-822D-93B27CA7262F@pooteeweet.org>
References: <413588E2-8AC8-49F7-B7BF-97BEFB0A71E4@pooteeweet.org> <bcb7aa500911100900n7c7c5dbexf5ad369134584c58@mail.gmail.com> <4AF9B5B8.90104@zend.com> <536BF944-AB9D-4B5F-86CB-B75D3C0D7F63@pooteeweet.org> <4AF9B9FE.1040701@zend.com> <40A3B652-6B6A-49C1-9481-40AA6EC7537A@pooteeweet.org> <4AF9C13B.4030104@zend.com>
To: Stanislav Malyshev <stas@zend.com>
Subject: Re: [PHP-DEV] alternative to the fopen() hack in autoloaders
From: mls@pooteeweet.org (Lukas Kahwe Smith)


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
mls@pooteeweet.org