Re: simplifying raiseError

"Stig S. Bakken" wrote: > > Hi, > > Now that I'm in the process of adding ZE2 and exception support to > PEAR.php, it made me want to simplify the raiseError method a bit. It > carries around a lot of baggage from when "return new PEAR_Error" was > used, and before. The parameter order is the most visible proof of > this, the fact that you are able to override mode and options in the > raise call is another. Btw, please try to remove the $skipmsg param :-) Has no sense to have message _and_ code, when the developer is going to use only one of them at the same time. I we agree that error codes can only be codes (this is int values) we could remove one arg, but I let to you such discussion. > If you sympathize with this view, you may very well agree that having > "userinfo" as the fifth parameter, with two "dead" ones (mode and > options) that you have to set to null between, is cumbersome. So I'd > like to introduce a new method for raising errors with only three > parameters: error message, error code and userinfo. Some of the > original idea behind having error codes was to make I18N easier. In > practice it's not, so while I'm at it I'd like to get everyone's input > on how to integrate I18N better in the new error raising method. A current limitation of the PEAR Error system is that it can't handle dynamic error messages: "The max value is [int]" (and of course [int] may change its position in the string in a different language). So I guess we would need a system that can accept data to "bind" to the error message and placeholders for the messages (I'd vote for the gettext style): $this->raiseError("The max value is %s", null, null, $max); or $this->raiseError(null, SOME_CODE, null, $max); (the fourth param can be an array). We would like to add the placeholder replacement code too (well, just sprintf() may be enough here). For the translation it self, I guess that we are not going to agree in a unique way. In some cases I would like to integrate the errors messages in my gettext system and in others I would just like to use an array with translations. We could provide a way for developers to build their own message translation function (and why not, btw mapping codes to messages too), for ex defining a function which accepts the following args: getI18Nmessage($lang, $message, $code, $array_data) Then our getMessage() func could call it when it's present. For setting that we can use new methods like: bool PEAR::setLanguage($lang, $func_to_translate); array PEAR::getLanguage(); Just some thoughts. Tomas V.V.Cox