A new feature for SilverStripe should be ...

Replace extensions with traits

Extensions are quite slow, and PHP 5.4 introduced traits which does a lot of the same stuff but as a language feature (so is much faster).

One caveat is the event-like methods in Extensions (onAfterWrite, etc), but they can be replaced with an event system (see http://silverstripe.uservoice.com/forums/251266-new-features/suggestions/6425842-add-events-system)

Once that's done it'd be easy to replace extensions with traits.

It will require upgrading the minimum PHP version to 5.4, or doing some dynamic class compilation in the autoloader in 5.3 to maintain compatibility

35 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 →

    10 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...
      • Patrick Nelson commented  · 

        Re: Mar's comment on extensibility for *core* classes.

        Has anyone put much thought into exposing core functionality via service providers + facades, similar to how this is done in Laravel? I noticed that when I needed to roll out a modification to how something in the core worked, it was as simple as extending some of the core classes with my own classes, setting up a new service provider to point to that class and then update the facade alias (in bootstrap config) to point to my custom implementation instead of Laravel's default. It's pretty simple and it covers all of these bases.

      • Mark Guinn commented  · 

        I see extensions having two aspects - isolating reusable functionality and "mixing in" functionality to code you can't otherwise touch (core or vendor extensions). Traits are good at the former. Are you saying the latter would be addressed by events and DI?

        I can see that being true down the road but right now core is not even using DI enough to allow that, let alone extensions. I'd be all for starting to shift things like Hierarchy and Versioned to traits though as long as there is a way to do continue to "mix in" in the short term.

      • Conrad Dobbs commented  · 

        Would traits really work? I thought traits have to be defined on the class using the "use" syntax. So how would you then extend a core class like Member.

      • Aaron Carlino commented  · 

        Traits only "replace" extensions in the user space, though. A vast majority of what extensions are used for is augmenting core class definitions and database fields, etc. How would traits solve that problem?

      • AdminCam Findlay (Community Awesomeness Manager, SilverStripe) commented  · 

        Sounds like a good idea. We'll need to make sure and do some good documentation and code examples for this once it comes to fruition. The extension paradigm has been with us for ages so might require a bit of encouragement if we move to traits.

        Hamish, any chance you could write up your musings on traits vs extensions into a blog post that the wider community can digest and comment on?

      • Vinci commented  · 

        Yes Hamish this sounds awesome

      • __will commented  · 

        ill add a vote for this as hosting with 5.4 is now very common, especially compared with things like apc cache, which is kind of needed to run SS well. So no downside really.

      • Anonymous commented  · 

        Events make a much better solution to extensions if implemented correctly.

      • Marcus Nyeholt commented  · 

        When benchmarking the bootup process of SS, iirc the slowest part was the evaluation of _config.php files, largely because of add_extension calls that would trigger Config::update calls. I know that some modules trigger add_extension as a runtime function, but I believe the majority of these cases should be able to be expressed via the config system.

      • Hamish Friedlander commented  · 

        I think if needed the remaining limitations of Traits can be worked around with DI and code generation.

        Better if we had http://silverstripe.uservoice.com/forums/251266-new-features/suggestions/6425813-rework-extensions-to-be-less-dynamically-controlla though

        (Incidentally, dynamically adding extensions doesn't really work that well - if you have existing instances, some statics that are shared by all instances are updated, but other class-specific things aren't, so you end up with instances in a partially extended state. Removing extensions works even worse).

      Feedback and Knowledge Base