Re: PEAR Coding Standards question

From: Date: Tue, 19 Aug 2008 21:36:27 +0000
Subject: Re: PEAR Coding Standards question
References: 1 2 3 4 5  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-50571@lists.php.net to get a copy of this message
On Aug 19, 2008, at 16:24 , Lukas Kahwe Smith wrote:
On 19.08.2008, at 19:08, till wrote:
On Tue, Aug 19, 2008 at 12:58 PM, Chuck Burgess <demon.gene@gmail.com> wrote:
On Tue, Aug 19, 2008 at 11:49 AM, Chuck Burgess <demon.gene@gmail.com
wrote:
On Tue, Aug 19, 2008 at 11:39 AM, Kevin van Zonneveld < kevin@vanzonneveld.net> wrote:
Why are the coding conventions so that I'm not allowed to prefix protected methods with an underscore?
The decision on that was made on this old RFC [1]. Perhaps we should revisit it with a fresh discussion? -- CRB [1] - http://pear.php.net/pepr/pepr-proposal-show.php?id=99
The most helpful comment on that RFC that helps me understand the overall decision against underscores was from Justin -- "As protected members may be declared public in extending classes, it makes sense to me to not force protected members to be prefixed."
Wow, a true moment of clarity. Makes perfect sense to me. :)
It doesnt for me. While I am working inside the "guts" of a class (aka extending it), I am much more aware of the internal design, than when I am "using" it from the outside. As such the prefixing to me is mainly about informing how the properties/methods are accessible (or not) from the outside. As for as outdated or not, of course you can/should define it explicitly with the relevant keywords as well, but with the underscore you do not look things up, its right their in your face with casual inspection of the code/API docs.
Sorry to add to what looks like a brewing CS thread storm, but I must agree with Lukas on this one. 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 found it important enough for Solar, that it's the only item on which we intentionally deviate from the PEAR CS rules. <http://solarphp.org/manual:project_standards:style_guide> (Not to say that a non-PEAR project should dictate what PEAR does. ;-) -- Paul M. Jones http://paul-m-jones.com/

« previous php.pear.dev (#50571) next »