RE: [PEAR-DEV] coding recommendations

Factory is definitely the way to go for this situation. I cleaned up some code of mine that used to return an error object from the constructor when there was a problem (instead of the requested object). I used factory instead and was pleased to find that the code ended up being much cleaner and easier to understand. Also, I posted a bug about this issue but it hasn't been followed up on yet: http://bugs.php.net/bug.php?id=21380 Matt Friedman > -----Original Message----- > From: Alexander Merz [mailto:alexander.merz@t-online.de] > Sent: Sunday January 26, 2003 3:09 PM > To: pear-dev@lists.php.net > Subject: Re: [PEAR-DEV] coding recommendations > > Krystof Slaby wrote: > > > I'm not able to make it behave different > > what's wrong with it? do I make some (maybe fundamental) mistake? > There is no different if you call the parent constructors without > parameters. But if you set a own error class, you must use $this: > $this->PEAR("my_error_class"); > Else the call is senseless, because the name is stored in an instance > variable. > It's a current bug in php, that parent_class::method behaves like > $this->method, if used in a child_class method. Although while using > parent_class::method $this should not exist, it does it! > Thats the reason why pushErrorhandling and other PEAR-Error related > methods doesn't works correctly, and are still unusable. > > > system resources (such as free handles etc.) - if this fails, it's > better to > > pass an error than continue and pass an error when method is called > (though it > > must be also done), you get the hint that something went wrong and you > > Thats why the factory pattern was found. > > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php