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

> // I've realised that performSecretCalculation was a bad idea and got rid > of it. > > The point is that we in PEAR are creating things like performSecretCalculation(), while users are trying to re-use our code, and can run into design limitations like the above. Typically, when you discover these problems, it's buried 18 layers deep in the guts of a class. A really good example of this kind of design choice biting end users: HTTP_Request vs unit tests. How did you convince the class to only do mock HTTP requests without writing an abstraction layer? See http://svn.php.net/viewvc/pear/packages/HTTP_Request/trunk/Request.php?view=markup#l690for an idea of what I'm talking about here - there are 21 different private variables/methods used there (each multiple times). _allowRedirects _buildRequest _generateHostHeader _headers _http _listeners; _maxRedirects _method _notify(); _protocol; _proxy_host _proxy_port _readTimeout _redirects _requestHeaders _response _saveBody _sock _socketOptions _timeout _url If I wanted to mock those out, and the private keyword is used on any of them, I'm out of luck - I have to cut and paste to reimplement. HTTP_Request2 changed this by allowing adapters, including mock adapters; which works really really well. There's nothing enforced as private there, I can extend anything I need to, etc. It took from 2002 with the original HTTP_Request class until 2008 for HTTP_Request2 to realize, learn from and fix this design flaw, and if it had been enforced by PHP5's private keyword, that would have been tens and hundreds of bug reports from our users as they each got bitten, or ignored our classes as useless for their purposes. > Thanks to encapsulation, your class still works (you have copy of method > I've removed). Mine could be freely refactored. > So, you fix a bug in your implementation of performSecretCalculation, I don't notice and re-copy and paste, which means there's no point me extending your class in the first place: I might as well write the whole thing from scratch. The whole point of a project like PEAR is to provide a set of robust, reusable components; not make our users rewrite everything. > > That's a huge can of worms to open just so that someone may avoid > copy&paste of methods that he wasn't supposed to be using in a first place. > > The main problem I have is with "Wasn't supposed to be using" - you as the original class author know nothing of what this user needs for his unique situation. Using code to blindly assert control leads to embarrassment - http://failblog.org/2010/02/07/censorship-fail/ Original design (visible to you, author of Swearblock): Block swear words under all circumstances. Actual needed design (visible to me, web developer selling free willy DVDs for my company): It's perfectly reasonable to block swear words, but exceptions need to be catered for. Imagine how angry that web developer is if the PEAR library he's using refuses to let him make exceptions, change behaviour, or otherwise tailor things for his needs without a significant amount of investment.