Re: Re: [PEPr] Comment on RFC::ProtectedMembers
| From: | Hans Lellelid | Date: | Sun, 27 Jun 2004 16:02:11 +0000 |
| Subject: | Re: Re: [PEPr] Comment on RFC::ProtectedMembers | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-31255@lists.php.net to get a copy of this message | ||
Klaus Guenther wrote:
You're making a mistake here. It was in existance _before_ PHP5. Your argument basically states that CS is stupid. I'm sorry, but I don't agree. You base everything on the fact that the underscore for protected items is new. It is not. It is a PEAR requirement.I disagree. (I thought you did too). PEAR-PHP4 had one protected/private/dont-touch-this setting for vars. protected != private so PEAR-PHP4 really didn't have this at all. With protected You are allowing others to vars and you are required to make sure they don't change or you will break BC. Protected vars can be declared public by child classes.
If you believe it does not make sense, support the RFC against it. But don't whine about it being "ugly" or that people "who don't use PHP5" are forcing it on others. Realize that you are trying to remove this requirement from the PEAR coding standards.Yes, fair enough. I don't like whiners. I'm going to post a response showing, lastly, what I feel is a last practical concern. It'll be good to use some code.
I think Lukas and Alan make a good point about remote host usage. This certainly helps prevent mistakes. If anyone says something about writing a new editor just for that purpose, it shows nonsensical hostility of the person who says that toward other coders. Write it yourself and then others might agree with you.No, this is certainly the weakest part of the argument. The idea that coding standards should be built around the ability to make modifications to fielded packages deployments is crazy. I should hope that anyone updating a package on a fielded box would have tested their changes locally or would otherwise know what they are doing.
Wrong: private members are subject & free to change without notice. Changing protected members is a BC break for any class that extends yours, which is the only reason to label a var 'protected'. HansSo, would PHPUnit2 be forced to break BC and prefix all protected members with '_'?Yes, but get this: it wouldn't be a BC break, because all private/protected members are subject to change without notice anyway.