[buddypress-trac] [BuddyPress] #4470: BuddyPress Singleton

[buddypress-trac at lists.automattic.com]

#4470: BuddyPress Singleton
------------------------------+------------------------------
 Reporter:  johnjamesjacoby   |       Owner:  johnjamesjacoby
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  1.7
Component:  Core              |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |
------------------------------+------------------------------

Comment (by johnjamesjacoby):

 Replying to [comment:5 foxly]:
 > I wasn't talking about the specific PHP code in the patch, I was talking
 about the design philosophy implied by the source code comment.
 There are variables (version/db_version) that shouldn't be tampered with
 by third party plugins.
 > Making vars and methods private will cause you EPIC problems. Since PHP
 has no concept of "friends" like the C language family, there's no way for
 unit test code to "tamper" with a class' internal variables as part of the
 test process. It can also cause frustrating problems with debugging,
 because variables you think should be there are "invisible".
 No method scopes have changed here, nor is there any reason for them to.
 > Build-out your unit tests with Razor. When you're done (and you actually
 have tests with decent code coverage) its unlikely you'll still be so keen
 on locking-down BP's classes.
 I'm keen on us locking things down that are appropriate to lock down.
 You're arguing both sides: !BuddyPress isn't mature enough to make
 visibility changes to -- write unit tests for what is apparently an
 immature platform. Which is it?

 Both rules do apply, but to different portions of !BuddyPress's code. This
 change, currently has very little to do with either of them, or anything
 else you've brought up so far.

 Why a unit test would want to "tamper" with variables outside of the
 boundaries !BuddyPress internally allows defeats the purpose of that test,
 since it will clearly always fail; rightfully so.

 The lengthy clean-up efforts of 1.5 and 1.6 enable us to work towards a
 goal of protecting third party plugins from each other, preventing users
 of !BuddyPress powered sites from seeing wp_die() messages they shouldn't
 see, and protect !BuddyPress developers from themselves and each other,
 similar to !WordPress's _doing_it_wrong() function.

 Where the idea came from that it's anyone's intent to lock everything
 down, I'm uncertain. It's an incorrect conclusion to jump to.

 I want you to know I appreciate your attention to detail in matters like
 this. In the extreme cases you describe, there is no benefit or reward
 from making this change. Please understand that those cases do not
 actually exist, and as such are not worth addressing at this time.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4470#comment:6>
BuddyPress <http://buddypress.org/>
BuddyPress