This is a paradigm shift from the current scheme, which avoids this in favor of underscores and direct naming. However, in 1.4, it makes sense to consider autoloading instead of the current scheme. This would likely lead to better segregation of classes in the file structure, as well as a removal of the need to explicitly invoke require.
One scheme as used in OPT (formerly MWRS) uses a flat structure, separating into controller, library, model, exception and interface directories based on name suffixes like Main_Controller, DB, Active_Record_Model, DB_Exception and DB_Query_Interface. However, this is very different from PSR-0.
From a post in bcabb1479c30929982c4f1e7c1e50ce0b69c0370, Rich presents a case for conforming to PSR-0:
The standard that I was referring to is PSR-0. What I was trying to say was that if one follows PSR-0,
it will preclude having class files named both "foo.php" and "Foo.php". (SR = standards recommendation,
so I probably should not have referred to it as a standard.) https://wiki.php.net/rfc/splclassloader)
You could argue that, as far as naming conventions go, I'm reading too much into the standard...er, I
mean standard recommendation. It's possible to think of ways where you could get away with naming
a class file without any upper case characters. But they all strike me as self-evidently unwise. (For
one thing, they would generally require that your file name not correspond to your class name.)
Moreover, every single example given under "Examples of Namespace Resolution" uses mixed case
in the same exact way. These examples are from Symfony, Zend, and Doctrine. If it works for those
frameworks, I'm not too worried about it creating problems for us. Without a doubt, their installed base
on case insensitive operating systems greatly exceeds ours.
I'm not sure I agree with the statement "they would generally require that your file name not correspond to your class name", as autoloading can easily be handled without upper case. In a flat structure, suffixes can specify different class types. In a deeper directly structure, it could be accomplished by using namespaces as packages even beyond the vendor portion in PSR-0 (since this is now a PHP 5.3 application). I'm not sure I understand why directories can't be driven by namespaces alone and they recommend both underscores and namespaces converted into directory separators.
I think we'll want to come up with some naming proposals for 1.4 before moving forward - we will discuss more in the next core dev meeting - but this will definitely be something to address for 1.4 to enable an autoloader.
Rich has pointed out that an outstanding recommended standard PSR-0 suggests mixed case naming: https://wiki.php.net/rfc/splclassloader
This is a paradigm shift from the current scheme, which avoids this in favor of underscores and direct naming. However, in 1.4, it makes sense to consider autoloading instead of the current scheme. This would likely lead to better segregation of classes in the file structure, as well as a removal of the need to explicitly invoke require.
One scheme as used in OPT (formerly MWRS) uses a flat structure, separating into controller, library, model, exception and interface directories based on name suffixes like Main_Controller, DB, Active_Record_Model, DB_Exception and DB_Query_Interface. However, this is very different from PSR-0.
From a post in bcabb1479c30929982c4f1e7c1e50ce0b69c0370, Rich presents a case for conforming to PSR-0:
I'm not sure I agree with the statement "they would generally require that your file name not correspond to your class name", as autoloading can easily be handled without upper case. In a flat structure, suffixes can specify different class types. In a deeper directly structure, it could be accomplished by using namespaces as packages even beyond the vendor portion in PSR-0 (since this is now a PHP 5.3 application). I'm not sure I understand why directories can't be driven by namespaces alone and they recommend both underscores and namespaces converted into directory separators.
I think we'll want to come up with some naming proposals for 1.4 before moving forward - we will discuss more in the next core dev meeting - but this will definitely be something to address for 1.4 to enable an autoloader.