Proposals (Political/Workflow) #4473
Drop PSR-0 for main autoloader
PSR-0 should apply to only vendor/ classes and be implemented as a secondary autoloader; along with other standards, for the sake of dealing with non-kohana dependencies.
There is no advantage to be gained from having PSR-0 as primary autoloader; not with how kohana currently works. The people who've made it likely never ever even touched a CFS so it's unlikely kohana's structure was even an afterthought in it's development.
It's understandable that things like namespaces aren't essential for everyone (nor a critical part of the standard) but they are essential for some of us, and WILL inevitably become essential as a codebase grows and naming becomes a problem. PSR-0 doesn't help at all and namespaces using it and the current interpretation of it just produces weirder code which is just going to be a nightmare to work with moving forward. Who wants to work with a whole bunch of weird namespaces combined with a bunch of non namespaces code and name conflics with kohana modules that still use global space? Not to mention
Some\Class_Name conflics and ambiguous file paths. Even the current system works better then the PSR-0 / CFS hybrid.
Alternative primary autoloader: https://github.com/srcspider/Cascading-Class-System Should even work fine with a slightly altered version of the current autoloader for backwards compatiblity since it handles only classes with a namespace.
#1 Updated by Isaiah DeRose-Wilson almost 3 years ago
- Priority changed from High to Low
This is not a high priority. We had a long discussion before psr-0 was implemented and we aren't about to remove psr-0 support now. If it turns out it doesn't function as well as we hope we can reevaluate it for some future version of Kohana (most likely 4.x).
#2 Updated by Steven G. almost 3 years ago
Isaiah DeRose-Wilson wrote:
We had a long discussion before psr-0 was implemented and we aren't about to remove psr-0 support now.
If you're referring to this: http://dev.kohanaframework.org/issues/4001 then I don't really see how much value in the discussion is there when the only reason for adding it in is:
- every other framework is doing it
While everything else there points to potential problems:
- unusable namespaces standard
- case sensitive names going against how PHP works and causing potential invisible errors cases
- URL problems
- ambiguity in class definitions
(Just going from what was said in the issue alone)
I'm sure there's probably been more private discussion. If there's actually some positives to it then I would like to know. Right now the move to go with it seems extremely and unnecessarily rushed out the door.
If it turns out it doesn't function as well as we hope we can reevaluate it for some future version of Kohana (most likely 4.x).
What exactly are you hoping for? Everything it does is a (potential) problem. And for what it's worth you wouldn't be using it with namespaces so it's essentially less flexible then the current/old loader.
#3 Updated by Z Binzl almost 3 years ago
Frameworks like Symfony and Laravel can make PSR-0 work with autoloader classes configured at runtime. But even the idea of transparent extensibility is alien to Symfony - the classes are stuffed with private methods and properties. Laravel manages it with configuration over convention, IoC container, etc. Fuel just cheats by aliasing everything to the global namespace.
It's all very different from the Kohana way ... but still collisions are a problem that will really need to be addressed sooner rather than later, so I hope the issue won't be kicked into the long grass. Maybe there should be a cash prize for the best solution. :-)