Re: Some PEAR remarks

> >> A question in advance: why are member variables in PEAR prefixed with a > >> '_'? Sure this is useful in languages like Java or C++ where it's hard > >> to see which variable is a local one, an argument or a member, but in > >> PHP this distinction is already clear: all member variables are > >> prefixed with '$this->' inside a method. And if you use proper > >> encapsulation, member variables are never accessed from anywhere else. > >> (And very, very sadly, this is not the case in the PEAR library!) > > > > http://pear.php.net/manual/en/standards.naming.php > > I know that they're following a standard, but I question the standard, not > the fact that PEAR uses it :-) > > The only use I see is in prefixing private methods with a '_'. But as I > said, there's simply no need to prefix member variables, as they should > always be private, and are always discernable by the way they are accessed > through '$this->'. The thing about PHP is there is no enforcement of private variables or methods in the language. If something is in a class, anyone can use it, e.g. class Duck extends PEAR { $var _preen=True; //private $var _numFeet=2; // private function _layEgg { echo "Quack"; } // private } $duck = new Duck(); $duck->_preen; $duck->_layEgg(); $duck->_numFeet; The _ convention as I understand it is a cue for users of a class that something is private. It doesn't prevent anyone from going ahead and using it, but it does at least provide a warning. So, you know to never use a classes "_"-prefixed methods or variables outside a class. > > I wonder if you have ever worked in actual production then? Databases go > > down, connections get changed, things happen. If an error occurs > > somewhere along the line, I need to know about it. The idea that once > > code is in production it doesn't contain errors, or errors won't occur, > > is asking for trouble. > > As I said earlier, there should be a clear distinction between the kinds > of errors. Supplying an incorrect DSN is like forgetting a brace: those > mistakes are made, but once fixed they never turn up again. It's these > kind of errors I talk about: an application in production state doesn't > have them, because the application wouldn't run otherwise. Another > example is that sometimes it's necessary to enforce some kind of method > calling order: "before calling 'execute()', the method 'initialize()' > must have been called first." Not judging the design of this code, there > are various ways to handle this. The execute-method for example could > check if initialize has been called, and if not do so. But this might > require an additional internal flag you don't really want. On the other > hand, in production code, this error can and will never be made. So why > check for it, slowing down the code? There are more types of errors than code errors. Say your database fills up. Say a user enters something incorrectly. Having a rich error handling class allows you to do more than just check if a function returns Success or Failure. How you handle an error is up to you, but you're much better equiped to handle an error when you know what happened, versus only knowing that _something_ when wrong. When PHP itself supports throwing exceptions, destructors and has a richer set of OO operations, I'm sure that the PEAR base class will be able to shrink accordingly. See below for some of the features that will appear in Zend2. With your experience in OO, perhaps you could help the Zend2 development team design these features. http://www.zend.com/zend/zend-engine-summary.php http://www.zend.com/engine2/ZendEngine-2.0.pdf - Brent