Bug #49625 [Com]: spl_autoload and case sensitivity

From: Date: Wed, 02 Jul 2014 10:43:00 +0000
Subject: Bug #49625 [Com]: spl_autoload and case sensitivity
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-186421@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=49625&edit=1 ID: 49625 Comment by: tom at r dot je Reported by: jo at feuersee dot de Summary: spl_autoload and case sensitivity Status: Not a bug Type: Bug Package: SPL related Operating System: Linux PHP Version: 5.3.0 Block user comment: N Private report: N New Comment: One thing everyone here seems to be missing here is that php classes are not case sensitive: This code will execute correctly: class FooBar { } new foobar; new FooBar; new FOOBAR; new fooBar; However, add autoloading into the mix and you create action at a distance that isn't immediately obvious: if the class is in FooBar.php and you have a case-sensitive autoloader then this executes: new FooBar; new foobar; but this does not: new foobar; new FooBar; Should the order of operations here have any affect on whether this script runs successfully or not? Even worse, lets say you have: function a() { new FooBar; } function b(){ new foobar; } function c() { a(); b(); } What's even less obvious is that if the implementation of the a function changes to no longer need the FooBar class, the c function stops working. To the developer working on the a function, the implementation has changed but the API has not so should have no negative effect on anything external, yet another part of the application now breaks for no obvious reason. The PHP Developers are correct that this is not a bug and it's more sensible for the autoloader to be case insensitive. One of two things need to happen: 1) All autoloaders should be case-insensitive OR 2) PHP enforces case sensitivity on all class names. Previous Comments: ------------------------------------------------------------------------ [2014-06-24 15:08:34] me at mhlz dot de I just spent 2 hours to get the naming conventions inline with all the other OOP languages out there (meaning CamelCase filenames) only to find out that spl_autload is broken. This needs to be fixed. It is completely unexpected behaviour (if it tries to load "Class" it should be able to locate "Class.php". If backwards compatibility is such a big problem, then please add some kind of flag for it. It's ridiculous that you have to work around this "feature". ------------------------------------------------------------------------ [2013-11-09 23:36:38] moon at quantentunnel dot de I'm sorry, my last post was not correct, case 3 does not work :-( ------------------------------------------------------------------------ [2013-11-09 22:53:37] moon at quantentunnel dot de After searching around a while I found a workaround without performance loss. 1. Slower but not working with camelcase class files (like "MyClass.php"): spl_autoload_register(function($classname) { require_once(__DIR__ . '/' . str_replace('\\', '/', $classname) . '.php'); }); 2. Faster but not working with camelcase class files: set_include_path(get_include_path() . PATH_SEPARATOR . __DIR__); spl_autoload_extensions(".php"); spl_autoload_register(); spl_autoload_register( function($classname) {} ); 3. Faster and working with camelcase class files: set_include_path(get_include_path() . PATH_SEPARATOR . __DIR__); spl_autoload_extensions(".php"); spl_autoload_register(function ($classname) { spl_autoload($classname); }); ------------------------------------------------------------------------ [2013-05-15 12:19:46] martijn at 51north dot nl There's a few things I'd like to add (actually a lot but it's probably best if I keep most of it to myself): sjoerd@php.net: "it will break scripts which depend on spl_autoload being case insensitive." This suggest that right now spl_autoload is in fact case insensitive, which it is not. A case insensitive system should find Core.php when asking for Core.php, just like a case sensitive system would. The difference is that it would ALSO find core.php which would be fine by me. Now it fails to find Core.php making it case destructive at best. wim at asgc dot be: "In addition I would strongly suggest the __autoload function will not be deprecated until this is fixed." Thank god I love irony, however, this won't actually be a problem as you can still use custom auto loaders. All you need to do is register it using spl_autoload_register(). And finally, when using namespaces it is quite easy to get around this problem using a short autoloader function: function SPL_autoload_suxx($class) { include \str_replace('\\', '/', $class) .'.php'; } \spl_autoload_register(__NAMESPACE__ .'\SPL_autoload_suxx'); All you have to do is copy, paste and mop up the river that you've cried. ------------------------------------------------------------------------ [2013-03-22 17:45:26] abr28 at cam dot ac dot uk Like so many others I also think this is a much too obvious bug, unexpected behaviour, etc ... you name it. It's a poor implementation that needs to be fixed even if it means breaking compatibility with PHP code that relyies on it, code + files which are poorly cased anyway (!). However you can maintain compatibility by introducing a new function which alters a case sensitivity flag. Just like you already have spl_autoload_extensions() to hint/restrict the extensions for spl_autoload(), you can have a function spl_autoload_case() and call it once, e.g.: spl_autoload_case(false); // for the broken lowercase spl_autoload() spl_autoload_case(true); // to respect case sensitivity You'd call this before spl_autoload() gets called. You can even make the default to be lowercase, like you so insist on having. This way you don't break compatibility -- although you should(too many aspects of PHP encourage bad coding already). ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=49625 -- Edit this bug report at https://bugs.php.net/bug.php?id=49625&edit=1

« previous php.bugs (#186421) next »