Have SilverStripe classes be in namespaces
Right now all SilverStripe classes are just in the global namespace. We decided 5.3 would be a reasonable requirement too late in the 3.x cycle to change this.
However it's holding us back, and we can't really wait for 4.x to fix it.
We should move all cms & framework classes into appropriate namespaces (ideally PSR-0 compliant, although this wouldn't include making PSR-0 actually work, we'd still need the SilverStripe bootstrap, at least for now).
We'd need to include a tool that scanned projects for class usages & automatically added the use statements to the top of all files for easy upgrading. It would almost certainly mean modules would need seperate 3.1 and 3.2 compatible versions though (although that already happens with 3.0 and 3.1)
We’ve released this as part of 4.0.0 – hooray! https://www.silverstripe.org/blog/good-things-take-time-4-0-0-stable-released/
Emil Kjelsrud commented
I agree with Stephen. PSR-4 should be the standard to adopt, not PSR-0.
Damian, is there an issue raised on github for this? I'll mark as in progress and provide a link to the work incase anyone else wants to help.
Damian Mooyman commented
This item is in progress. Hamish please mark as such. :)
Michael Strong commented
100% support this.
Here are a few issues i've had using namespaces with the current setup:
1. The current template logic isn't possible on all OSs. For example if we have a class named \SilverStripe\Form\Form then the template for Form needs to be exactly the same (including backslahes). I have played about with replacing backslashes with hyphens which works fine, but you end up having really long filenames and you'd still need to support BC.
2. Any DataObject subclass is not aware of its current namespace during the manifest build. This means MyDataObject must extend \DataObject (rather than 'use \DataObject'). This goes for subclasses too (MyDataObject extends \some\other\really\long\namespace\MyDataObject). If you don't do this, it will cause unexpected issues. From memory, ModelAdmin doesn't like it and its really hard to debug as it doesn't give an error related to namespacing - just that the table doesn't exist.
On the point of PSR-ness, SIlverStripe should be targeting PSR-4 compliance, as PHP-FIG are doing everything they can to deprecate PSR-0.
Modules are going to have to require 3.1 / 3.2 versions anyway aren't they due to the ORM changes? I know several modules error on 3.2 currently due to the ORM change.