A new feature for SilverStripe should be ...

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)

77 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Hamish Friedlander shared this idea  ·   ·  Admin →

    6 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Emil Kjelsrud commented  · 

        I agree with Stephen. PSR-4 should be the standard to adopt, not PSR-0.

      • 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.

      • Stephen commented  · 

        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.

      Feedback and Knowledge Base