I have some more Zend_Loader tests to commit as well

To:Emil Ivanov
Thanks your comment. But Unfortunately, I can not use filename in openFile method of SplFileObject.

Symptoms: My rendered views no longer worked as if the files template files were not being read. (Note, I use a Smarty/ViewRenderer solution)

I made a patch in my local copy by placing your suggested is_readable($filename) check above the directory path traversing.

I see you had posted on May 7th the inclusion of the is_readable($filename), I believe it should be added for consideration.

<code>
public static function isReadable($filename)
{
// If the directory methods above don't work, try the filename directly
if (is_readable($filename)) { return true; }

$dirs = explode(PATH_SEPARATOR, get_include_path());
$dirs = array_merge($dirs, array('.'));

foreach ($dirs as $dir) {
if (is_readable($dir . DIRECTORY_SEPARATOR . $filename)) { return true; }
}

return false;
}
</code>

Thanks,

Do not use openFile, use $f = new SplFileObject($filename, $mode, $useIncludePath);

Buy the way I hear ZF Dev Team members works on this matter.
I will wait their to expect good results.

I think isReadable should also search in the default root, not using an includepath, so I did as follows:

/**
     * Returns TRUE if the $filename is readable, or FALSE otherwise.
     * This function uses the PHP include_path, where PHP's is_readable()
     * does not.
     *
     * @param string   $filename
     * @return boolean
     */
    public static function isReadable($filename)
    {
    	$arrPaths = explode(PATH_SEPARATOR, get_include_path() );
    	
    	$blnReturn = false;
    	
    	if(  file_exists( $filename ) &&  $fh = @fopen( $filename, 'r') ){
    		@fclose($fh);
    		$blnReturn = true;
    	}else{
	    	
    		if( substr($filename, 0, 2) === './' ) $filename = substr($filename, 2);
	    	
    		foreach($arrPaths as $path){
	    		if( substr($path, -1, 1) !== '/' && substr($path, -1, 1) !== '\\'  ) $path .= '/';
	    		
	    		if ( file_exists( $path . $filename ) &&  $fh = @fopen($path . $filename, 'r')) {
		            @fclose($fh);
	    			$blnReturn = true;
		        }
	    		
	    	}
    	}
    	
    	

        return $blnReturn;
    }

Second, the fopen() call also has the error suppression operator; you will only see these errors in your error log. This is acceptable when it comes to E_STRICT standards – the spirit of this rule refers to the messages that will be displayed when display_errors is on. This is one reason why error suppression is discouraged – it should be used only for very, very good reasons. This is one such case, to our thinking.

I thank you that you explain why fopen() should be selected than other ideas.

I think this issue should be closed as 'Won' t fix' , do you think?

I wondered why fopen() with at mark happens.
Because I did not find any warning in my tests with ver.1.6.1, 1.6.2, 1.5.3 and etc.

I understand what causes the warning, by talking about Simon on ZF-2900.
I recommend to look at that issue to solve this issue.

According to my tests, your fopen-based method is always 5-30% slower than my "looping over paths in userland code" method.

Here's my test code:
first add the new method to Zend/Loader.php:
public static function _isReadable($filename)
{
if (is_readable($filename)) return true;
foreach (explode(PATH_SEPARATOR, get_include_path()) as $path)

return false;
}

Now run test:
<?php
set_include_path(implode(PATH_SEPARATOR, array('/path1', '/path2', '/path3', '/path4', '/path5', '/path6')) . PATH_SEPARATOR . get_include_path());

require_once '/ZF/library/Zend/Loader.php';

$start = microtime(true);
for ($i = 0, $count = 1000; $i < $count; $i++)

$stop = microtime(true);
echo 'Using new method: ' . ($stop - $start) . ' seconds<br />';

$start = microtime(true);
for ($i = 0, $count = 1000; $i < $count; $i++)

$stop = microtime(true);
echo 'Using old fopen-method: ' . ($stop - $start) . ' seconds<br />';

?>

Var_Dump.php is part of PEAR, and was just added to test for existing files in include_path (assuming PEAR path is part of include_path).

You could try commenting out the call to set_include_path(), or calls to both methods using nonexisting file or existing file, just to check that the resulting times are always similar when given similar input. The two methods also provide the same actual results, of course.

Could you please change this now, or do you need more proof?

This change will not effect performance (noticeably anyway).

You may close this again unless there were other reasons than my comment in ZF-2900.

Closed issue again as the mentioned code is not reproducable and already fixed within the actual release.