Tomas V.V.Cox [2004-06-26 15:59 UTC] I assume that for private members the underscore is a must. I'd add that to the RFC.
Alexey Borzov [2004-06-26 18:06 UTC] The RFC looks like an attempt to sneak the underscores in. The voting on pear-dev was against underscores, but less than +5. Now, if the proposal fails, we automatically get underscores.
I suggest changing the rules as +1 *for* prefix, -1 against prefix. Thus Hungarian notation lovers will have to rally to vote, not the saner folk.
Klaus Guenther [2004-06-26 18:51 UTC] The problem with Alexey's proposal is that he ignores the fact that maintaining status quo does not require people to jump through hoops. This is the basis of democracy and the PEAR voting system. This RFC proposes to /change/ the status quo. Therefore, it is properly formulated.
Alexey Borzov [2004-06-26 20:57 UTC] Last time I checked, there was no "status quo" on protected vars/methods, thus nothing to maintain.
Klaus Guenther [2004-06-26 21:07 UTC] The current standard states that any method or property prefixed with an underscore is for internal use. The proper understanding of such methods and properties is that they are protected, not private. The php4 "@access private" means that the marked methods/properties are private/protected. In other words, that they are non-public. (If the manual states it in any other terms, it is completely belied by usage.)
It does not mean that they are private in the same sense as the term is used in php5 or other OO languages. If you want to see this demonstrated clearly, look at the HTML_Common base class. The prefixed properties and methods are used in extending classes. HTML_Common has no purpose in and of itself.
However, I do see a definite merit in clearly marking a difference between private and protected items. This need is almost stronger than any need for marking protected items. So I'm wavering here between the positions :-)
Daniel Convissor [2004-06-27 16:57 UTC] This topic has already been discussed and decided on the pear-dev mailing list:
Discussion: http://marc.theaimsgroup.com/?t=108663666200004&r=1&w=2
Vote: http://marc.theaimsgroup.com/?t=108735027400001&r=1&w=2
The final vote was:
11 no prefix
9 for "_" prefix
1 for using "@access protected"
Raising this issue again is supurfluous and causing a tremendous volume of unnecessary discussion. Don't all of us have better things we can do with our time?
Please withdraw this proposal.
Aidan Lister [2004-06-27 17:07 UTC] Daniel,
This RFC was created in the heat of the issue, I've just been slow in taking it to the proposal stage.
This is an important decision, a simple email vote (which was anything but simple) does not cut it. It was suggested numerous times in the course of the "voting" that this be taken to PEPr.
If the result is already officially decided ofcourse I'll delete the proposal. If not, then clearly this needs to happen?
Alan Knowles [2004-06-28 04:57 UTC] One considerations I've not seen so far, is the logic (apart from private/public) for visually marking properties/methods with $_underscore is such:
One of the key reasons for prefixed properties/methods is the visual expression of "Do not mess with this variable/method, I may remove/rename it in the future." - hence as child classes are expected to rely on that variable always being there, they should not have that marker..
Aidan Lister [2004-07-03 16:52 UTC] Although this is pretty much settled, I suppose we should do it for official purposes anyway.
|
