Re: Some PEAR remarks

On Wed, Apr 17, 2002 at 03:55:29PM +0200, Vincent Oostindie wrote: > On Thu, 18 Apr 2002 02:08:47 +0200, Jason Lotito wrote: > 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->'. functions in a class called with that class are also prefixed with $this->, futher PHP doesn't has an property mechanism. Mostly 'public' variables are abused to have some sort of properties. I prefer to use 2 function for each property (getX() and setX($Value)), but that's just my style I agree with the fact that all variables in a class needs to be private. ZE2 contains those options, but PHP4 not. So everything is *always* public. The @access comment makes clear whether a function/variable is public or private > The answer is - again - to use smaller methods. Instead of jumping > halfway out of a method with some error object, break a method up into > two parts. This allows for greater flexibility on the side of the > application programmer. > > > 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? I'll bett i can more thing that can go wrong in a production state that you can tell me what go go right! Most developers don't have access to hardware and/or servers. We have Systems management for that. And except from all the hardware error you can find (broken network cable, no more space on your harddisk, UPS'ses that don't work with a power failure) and those of the managers. They accendently erased a database. Database servers can crash (Even the *nix servers ;-( ). There's a lot that can go wrong i a production enviroment. I even bet that aside from developer bugs (in the web app) that are going more thing wrong in production state than in development stage. Most e-commerce sites have the time of the year around christmas. More visitors, more database access, no more resources availible...) I have seen it al happen. Believe me, if somethings goes wrong, i want to know, how small it might be. > Also, when some error occurs 'along the line', at what point should it be > handled? Especially in a library, that should be up to the user of the > library, and not to the library itself. Oh, so your executing a query when you don't have a connection with a database?? Good luck.. PHP hasn't error trapping yet (try,catch is planned for PHP5), The only thing that you now can do i putting a @ for a statement. And i don't like that kind of 'on error resume next' options. > >> Much of the error handling can be simplified by introducting 'Null' > >> objects. These are objects of a class that simply do nothing. For > >> example, you could have a class DB_null that is just like any > >> DB_common-derived class, and is returned whenever a requested database > >> class doesn't exists (when calling DB::connect). It simply returns > >> default values from its methods instead of doing anything useful. This > >> trick makes using the library a lot easier, and of course it applies to > >> much more than just the DB class. So that you get back a null value of a sub-class that was called by the method of the class. Wait till you've tried derefering in PHP5 $object->method()->method()->method(). When the trirdh method raises an error and returning a null. You only that i go wrong, but not where. So you can't fix it.. I hate when that happens ;-) > When people first start to learn OOP, they find it very hard. After a > while they get used to it, and they think it's actually very easy. > Unfortunately, that's where most people stop learning. OOP actually IS > very hard, if you want to do it right. It's like riding a bike: once you > get the hang of it, it's pretty easy. But that doesn't mean you can > instantly participate in a marathon and expect to finish with the top 100! > It requires lots and lots of training to get there. > > > Unfortunately, PHP > > never claimed to be a OO language. Obviously, in ZE2 they are trying to > > fix that, and a lot of the things you discuss here can be done once it > > comes out, but right now, technologically, it's not possible. For a language that don't support and still tries to have some OOP capabilities i have to say that PHP4 has some great capabilities. Every looked at .NET?? Where PHP5 is going to support multiple inhertitance, C++ for .NET hasn't that anymore. You can only use multiple interfaces. I agree that a good OOP is dificult to make. But PEAR DB didn't started that big. People were just commiting one feature after another. And maybe it's indeed time to rewrite some stuff when PHP5 is there. But for Content Management Systems that have to work on multiple platforms and with several back-ends (real web applications) really need the PEAR DB. One interface to every database you want to access, and the only thing you have to do is changing the DSN. Another thing that most open-source projects are missing are requirements studies, functional- and technical designs. And i someone has made them, they mostly not committed to CVS. And without proper documentation every OOP design will finaly fail. But he, PEAR is open-source, so I invite you to (re)write some PEAR classes.. Dave Mertens