Re: [PEPr] Comment on Internationalisation::Locale_Maketext

Hans Juergen Von Lengerke wrote:

It comes from the basic idea that if you want to get grammar right, you may have to do this on a per-message basis (worst-case scenario). And if you want to encapsulate the logic for that very message, you want to put it into its own function. This is explained in the TPJ article. [...]

Now I see, many thanks for the explanation!

ps: extending PEAR is not a requirement

This is something I didn't understand about PEAR.php. If I use PEAR::raiseError() with PEAR_ERROR_DIE statically, can the Error be caught at all? And if it cannot, then why use raiseError() at all? I don't see the point. Can someone shed some light on this? By the way, the documentation shows no examples whatsoever on using raiseError() statically. On the same issue, I saw a comment somewhere that trigger_error() may be handled nicely in (future?) PHP. Now, honestly, are the classes PEAR and PEAR_Error really so useful then? Why?

Well, I just ment that it's not a requirement, but it might be useful in some cases. It for instance provides the option to set a specific error handling per instance, while the static call is controlled by global specified error handling options. class MemberCall extends PEAR { function err($static) { return $static ?

     PEAR::raiseError("dead\n") :
     $this->raiseError("alive\n");

} } PEAR::setErrorHandling(PEAR_ERROR_DIE); $o = &new MemberCall; $o->setErrorHandling('PEAR_ERROR_PRINT', 'huh? (%s)'); $o->err(false); $o->err(true); $o->err(false); The first call gets printed, thes second causes PHP to die. http://pear.php.net/manual/en/core.pear.pear.seterrorhandling.php Regards, Michael