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
SilverStripe have planned this item
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?
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?
Yes Hamish this sounds awesome
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.
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.
(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).