Re: PEAR_Error setters

> > I'm considering hard > > manipulation of the object returned($retval->code = MY_ERROR_CODE), but this > > is bad OO practise. > In alot of simple cases (like pear_error) - you will probably find the > conclusion is that introducing setters & getters to a already heavy core > component, is a expense not worth taking.. Well, PEAR::error is not that heavy a class, I must say. It just seems to have been designed with one goal. Call it to make an object, and bail out. The end-user can then do whatever s/he wants with the object by using the geters to fetch information about the errors.:) That said, I'm leaning towards setting and using my own error codes on PEAR::File's returned error objects for now. However, I'll also create a patch for File, to include error-return codes for all their raiseErrors(). Error codes which, magicly, have the same definition as the values my package will use;) That way, to the end user it'll be completely transparant as to which package exactly set these codes, since: <?php define("JUST_A_TEST", 1); define("ANOTHERTEST", 1); print(JUST_A_TEST == ANOTHERTEST); // true. ?> Ofcourse, I'm not saying I'll limit File just so my package works better :-) -- Cipri