[buddypress-trac] [BuddyPress Trac] #6853: Autoload BP classes

[buddypress-trac]

#6853: Autoload BP classes
--------------------------+------------------
 Reporter:  boonebgorges  |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  2.5
Component:  API           |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |
--------------------------+------------------
Changes (by boonebgorges):

 * keywords:  2nd-opinion has-patch => has-patch
 * milestone:  Awaiting Review => 2.5


Comment:

 Replying to [comment:3 slaFFik]:
 > Having `BP_{$component}_{$foo}` in 3rd party plugins is actually a bad
 practice. You know, prefix all the things and such. So in '''my''' opinion
 it should not be a blocking concern, as bad practices are a point of
 potential failures anyway (regularly, and developers should know that).

 I agree with this, and I don't think it'll be a major issue.

 Replying to [comment:4 DJPaul]:
 > There are admin classes we ought to support if we're going to do this,
 as well as template classes (that need splitting out into individual files
 -- there's another ticket for that).
 > Other than those two BP_Group classes, the others are all in the Core
 component, right? I am tempted to suggest we should rename those but that
 idea probably needs to wait until we discover what odd cases exist in the
 admin and template classes.

 See #6870, where I've outlined the task. IMO, we should do no renaming at
 this point - it's better to have a hash of inconsistently named classes
 than to break backward compatibility for the sake of aesthetics. When the
 day comes for full PSR-4 compliance, maybe we can talk about changing
 class names, and building a compatibility layer for it :)

 I think it makes sense to wait for #6870 before implementing autoload.

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