Re: PEAR Coding Standards question

On Aug 19, 2008, at 16:51 , Joe Stump wrote:

On Aug 19, 2008, at 2:36 PM, Paul M Jones wrote:

Having the underscore prefix as a visual hint that the method/property is not accessible from outside the class makes the most sense to me in this case.

I'm guessing your version of PHP5 works much differently than mine. When I use a protected or private member/method it's a fatal error.

No need for snarkiness, Joe. ;-) As an point of "style" and not of "functionality" (per se) I find the visual hint of the underscore very effective at helping to pre-emptively avoid those kinds of runtime errors. I try not to depend on a particular editor or IDE for that kind of thing, but that's just me.

When that functionality changes in PHP then I'm for bringing back the underscore. Underscores indicating protected/private are, basically, the vermiform appendix left over from PHP4 days.

Sometimes one discovers that old things may be of previously unknown importance: http://www.independent.co.uk/life-style/health-and-wellbeing/health-news/the-appendix-does-have-a-use--rebooting-the-gut-396277.html (OK, maybe that was retaliatory snarkiness -- sorry, could not resist. ;-)

2.) The underscore does *nothing* to indicate if it's protected or private.

It does if we say it does, but only as a point of style.

3.) It smacks of Hungarian notation. Why not just prepend everything with public_, private_ and protected_?

Because, contrary to my blog tagline, it is possible to take things too far. Cf. my defense of the 75-85 character limit ... http://paul-m-jones.com/?p=276 ... specifically the "balancing considerations" section at the end. I find the leading underscore to be non-intrusive and quite helpful, but of course reasonable people can disagree.

4.) If I ever decide to loosen access to a variable or method I actually have to break BC to loosen those restrictions as it stands. I can't simply make "private $foo" "public $foo" because it *has* to be "private $_foo", but "public $_foo" is a CS error.

I could be wrong here, but I thought BC maintenance was aimed at the public API of a package, not its internals. In that context, moving something from non-public to public wouldn't be a BC break, while moving from public to non-public would be. Again, I could have that completely wrong -- anyone have a definitive answer? I'll make this my last post on the subject, so as not to fan the flames any further. -- Paul M. Jones http://paul-m-jones.com/