Re: Re: alternative to the fopen() hack in autoloaders

From: Date: Wed, 11 Nov 2009 13:57:40 +0000
Subject: Re: Re: alternative to the fopen() hack in autoloaders
References: 1 2 3 4 5 6 7 8 9 10 11 12  Groups: php.internals 
Request: Send a blank email to internals+get-46028@lists.php.net to get a copy of this message
On 11.11.2009, at 14:50, Greg Beaver wrote:
Lukas Kahwe Smith wrote:
On 11.11.2009, at 11:44, Mikko Koppanen wrote:
On Wed, Nov 11, 2009 at 10:00 AM, Lukas Kahwe Smith
so a byte code cache should cache the resolution of the path thereby speeding up the subsequent call to include?
stream_resolve_include_path() as currently constructed could not be intercepted, and is actually unable to process an include_path that contains streams. I'm guessing it was written long before PHP 5.3. This could be easily fixed by having stream_resolve_include_path call zend_resolve_path() instead of doing its own internal calculations. With these changes, an opcode cache could easily cache the results.
ok.
As for your naming concerns, if we were to add an alias called is_includable() to stream_resolve_include_path(), that would be much clearer: if (is_includable($file)) { include $file; } The assumption here is that we are simply testing whether the file exists and whether php can actually read the file, not whether the file
Well I still maintain that is_includable() could imply for people that no error can occur. Just like when calling is_int() means that it really is an integer. so I still prefer "exists" or "resolve".
has syntax errors. A file with syntax errors is an exceptional situation, and should be handled by a clear fatal error, imo.
well the error raised for a syntax error or missing file would not change if we go in this direction. regards, Lukas Kahwe Smith mls@pooteeweet.org

« previous php.internals (#46028) next »