Hi Marcus, FYI, this change:
http://cvs.php.net/viewvc.cgi/php-src/ext/spl/spl_directory.c?view=diff&r1=1.146&r2=1.147 breaks about 20 tests in phar, it's a potentially serious BC break. I understand the reasoning behind it, but you may find other users up in arms. The main problem is that this line: flags = SPL_FILE_DIR_KEY_AS_PATHNAME|SPL_FILE_DIR_CURRENT_AS_SELF; returns the DirectoryIterator object as current instead of an SplFileInfo as it used to return. If you instead use: flags = SPL_FILE_DIR_KEY_AS_PATHNAME|SPL_FILE_DIR_CURRENT_AS_FILEINFO; this will at least keep the current behavior of a SplFileInfo class being returned. Perhaps the better course of action would be to correct the documentation rather than the behavior? People upgrading from 5.2.5 to 5.2.6 will have a nasty shock if they relied upon the default constructor parameters, and even if it is reverted in 5.2.x and kept in 5.3.x, the same problem holds. In other words, the best fix for this is to change the default value of $flags in the documentation of the constructor, not to change the behavior to match faulty docs. This is especially true since the value of the constant CURRENT_AS_FILEINFO was (incorrectly) set to 0 in the SPL module startup instead of the expected value - technically, the documentation (which says $flags = 0) is really saying $flags = CURRENT_AS_FILEINFO|KEY_AS_PATHNAME because it wasn't until this commit (http://cvs.php.net/viewvc.cgi/php-src/ext/spl/spl_directory.c?r1=1.146&r2=1.147) that you changed those values to non-zero. The fact that the constant was changed to the actual expected/documented value does not change the fact that it's not a good reason to break BC. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
