I tried looking for an answer to this myself, but couldn’t really find a final answer.
Background Story
When creating big applications, it becomes very handy to be able to create subdirectories to things like components. For example, I might want a [font=“Courier New”]“components/Api.php”[/font] file ([font=“Courier New”]class Api[/font]) that uses other classes that I would like to place under the Api directory (i.e. [font=“Courier New”]“components/Api/SubClass1.php”[/font]). Of course, I can’t really name the class [font=“Courier New”]“SubClass1”[/font] because that name may very well be used by another component class, so I have to name it something like [font=“Courier New”]“ApiSubClass1”[/font].
As we know, class names must be the same as the file names, so I would have to name my file [font=“Courier New”]“ApiSubClass1.php”[/font], which can get annoying. I should mention that I have to import [font=“Courier New”]‘application.components.Api.*’[/font] in my config file, which I don’t have a problem doing.
Time for a decision
Do I stick with this rather lengthy naming convention? Or do I just extend the autoload behavior to support Zend type autoloading (i.e. file name would be [font=“Courier New”]“SubClass1.php”[/font], class name would be [font=“Courier New”]“Api_SubClass1.php”[/font]). Also, I don’t feel like explicitely importing these subclasses is something I want to maintain in the future.
So… Why?
Why was this design decision made? Was it to optimize performance on not having to do any className string parsing in order to find the class file? Or is there a bigger/better/stronger reason?
Any input/thoughts appreciated 
),