[buddypress-trac] [BuddyPress Trac] #7218: Only load component action and screen code when we're on the component's page

[buddypress-trac]

#7218: Only load component action and screen code when we're on the component's
page
-----------------------------+-----------------------
 Reporter:  r-a-y            |       Owner:
     Type:  enhancement      |      Status:  reopened
 Priority:  normal           |   Milestone:  3.0
Component:  Core             |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-patch early  |
-----------------------------+-----------------------

Comment (by DJPaul):

 I am very excited by what this change represents.

 I've been trying to find a way to advance the state of the BuddyPress
 codebase for quite some time, while keeping most of our current
 (decisions? limitations? goals?) intact. What you've done here @r-a-y is
 better than the few ideas I've come up with (and mostly kept to myself),
 but also inspires me by setting a vision for the what the future of the
 codebase can look like.

 Modernising the codebase needs to be approached with care. It starts with
 what you've done here, and for the current patches, I'd like to offer just
 a couple of comments for review:

 * In each new class, we shouldn't not put the implementation inside the
 constructor. This can cause very subtle bugs regarding null-value
 (future?) class properties in certain load-order situations. That sounds
 vague, I can't remember the precise details, but I got schooled by this
 way back in 2009, just as I started using BuddPress, and I remember the
 incident vividly (hack day at my first WordCamp!).
 * In one of Boone's comments, he's suggested this and said maybe use
 static methods. I'd like to suggest we use regular instance methods.

 The flexibility this gives us, in terms of being to re-implement and re-
 name these classes in the future, is very liberating compared to what we'd
 have to do today.

 After these changes go in, we can then plan a modernisation strategy, the
 first steps of which involves adopting, more fully, dependency injection.
 In the long run, we'll be able to get to the point where we can retire the
 `$bp` global, because it'll be passed directly to classes that need it.

 In all, this change will set us on a road to making BuddyPress more
 testable, more clear, and more decoupled. Bravo, @r-a-y!

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7218#comment:35>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac