Re: [CFV] how to mark protected items?

From: Date: Tue, 22 Jun 2004 20:36:51 +0000
Subject: Re: [CFV] how to mark protected items?
References: 1 2 3 4  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-31119@lists.php.net to get a copy of this message
Hans Lellelid wrote:
Justin Patrin wrote:
Then, in your subclasses, you will start to ask yourself "Is this var protected or private, I can't remember".
And if there is no underscore or only an underscore for private, then you'll still ask yourself: "is this protected or public, I can't remember".
And then you're realize that it actually doesn't matter: if you're working inside the class you don't care & if you are accessing class properties from outside a class 1) you have read the docs to know of properties' existence 2) you will get E_FATAL if you somehow guessed at the name of some internal protected/private var.
I understand what you're saying, but I still think it's useful to have an obvious distinction between internal and public variables. At the very least, private members should have an underscore. Protected members still can't be accessed form outside of the class, so IMHO an underscore is still useful as it tells the user-developer (with a single look at the member's name) that they can't / shouldn't use the member.
It's not useful for PHP5 and there are already rules for PHP4, as Tomas mentions. I can see having an '_' for private members, because it's a clear indication -- and makes it clear for the class developer (which is the only person concerned in PHP5). Enforcing this seems a little arbitrary, since obviously no one else is gonna see those vars besides the developer. As Bertrand said, when every var is prefeixed w/ an '_' there is no meaning & it makes the code ugly.
Except when the docs either are nonexistant or don't help much. I find myself searching the code of a package much more often than going to the docs. It's generally quicker and gets me the answers I need. True, when looking in the code I can see the public / protected declarations, but it's still a quick reminder when there's a '_'. Besides which, if the "protected:" sits at the top of 200 lines of code, it can be easy to miss. Also, when looking at the use of members in the code, it's not obvious what is public until you go look at the declaration. And there is still a meaning. For those that *use* our code, it makes it much easier to spot what should be played with and what not. Besides which, we're still talking about PHP4 compatiblity.
Hans
-- paperCrane <Justin Patrin>

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