Re: Re: Getting rid of "underscore for private method names" codingstandard

On 16-01-2010 at 16:05:32 Greg Beaver <greg@chiaraquartet.net> wrote:

However, I think a *far* better suggestion would be to forbid the use of the private keyword unless the intention is to prevent any possible modification because of race conditions or other critical coordination issues.

I strongly disagree with this (unless by "critical coordination issues" you mean not breaking clients' derived classes and not being stuck with bad API forever). Protected fields and methods are part of public API. They're not really protected if your classes aren't final. If you make everything "protected", you actually expose all internal details. I think class author should consciously make decision how class can be extended, which means starting with everything private/final and then opening up appropriate API for extensibility. Otherwise class author may be unpleasantly surprised that there's other people's code relying on "protected" implementation details. Encapsulation is a trade-off between author's ability to change the class and extensibility/"hackability" of the class. If full backwards compatibility is required, then it should be tilted in class author's favour. Perhaps you've found case in PHPT where too much was encapsulated (I don't know - I'm not familiar with it), but there are cases where author may choose to make method private simply because he wants to remove/refactor it in next version of the class (even if there's nothing critical about it). I think having to ask author to open up a method is perfectly fine - it requires author to commit to that extensibility hook. It might be a simple and obvious thing, but it could be method that author doesn't want to support. Since burden of support is on author, it should be his decision. -- regards, Kornel