the number is not for speed, but rather to avoid all these parameters
within the C code. Save all the docref etc data in an XML file each per
language or in any other logic where also error strings will reside, but
leave the C code clean. This would be a good gain in practicity of such
method.
Again, I am not saying the details, but rather the idea of what I meant.
--
Maxim Maletsky
[EMAIL PROTECTED]
On Tue, 26 Nov 2002 02:40:21 +0100 [EMAIL PROTECTED] (Marcus Börger) wrote:
> A number is slightly faster but that is of no interest for error messages.
> More important is conflict avoidance and naming the extension in the
> error would be a fast first hint for us.
>
> Also we need the php_error_docref<n> forms and the other parameters.
> Especially the error category (E_<whatever>) cannot be removed from
> the parameter since it is the easiest way to differenciate between those
> errors which are continuable and those not.
>
> marcus
>
> At 02:26 26.11.2002, Maxim Maletsky wrote:
>
> >Yes, this is the way to go. but, I would still prefer to have to pass it
> >only a code like:
> >
> >php_error(255, data, data, data);
> >
> >where in an XML structure we can predefine everything else.
> >
> >
> >--
> >Maxim Maletsky
> >[EMAIL PROTECTED]
> >
> >
> >On Tue, 26 Nov 2002 02:19:35 +0100 [EMAIL PROTECTED] (Marcus
> >Börger) wrote:
> >
> > > At 02:03 26.11.2002, Maxim Maletsky wrote:
> > >
> > >
> > > >On Mon, 25 Nov 2002 22:18:32 +0100 (CET) Derick Rethans <[EMAIL PROTECTED]>
> > > >wrote:
> > > >
> > > > > On Mon, 25 Nov 2002, Sascha Schumann wrote:
> > > > >
> > > > > > Frankly, so far the discussion has been primarily
> > > > > > developer-focused, which is not too surprising. The
> > > > > > developers are rarely exposed to support requests from
> > > > > > newbies in various non-English forums.
> > > > >
> > > > > Thank god not; would you like to see your bugreports in french, or
> > > > > hebrew or finnish? If the error message is in a foreign language,
> > people
> > > > > are going to report bugs in that language too, and I dont think QA is
> > > > > waiting for that. Even with an error number attached is going to be
> > > > > annoying; I myself would not even bother.
> > > > >
> > > > > >
> > > > > > If PHP is supposed to become easier to use, then native
> > > > > > language error messages would be a big hit.
> > > > >
> > > > > Who says that PHP needs to be even easier then it already is? I think
> > > > > with the millions of users there are we're doing pretty okay I'd say.
> > > >
> > > >
> > > >This can be easily avoided. When I have to report an Oracle error in
> > > >Italian on an English page, I simply type the error code. We need to
> > > >introduce error codes in PHP, that would really solve the trouble.
> > >
> > >
> > > When using error codes we could supply a error-message-loader.
> > > php_error_docref would than not use fmt parameter but a number.
> > > The modules would then have to register their normal errors.
> > >
> > > For example:
> > > php_error_docref(NULL TSRMLS_CC, E_WARNING, "Error %d", error)
> > > would convert to:
> > > php_error_docref(NULL TSRMLS_CC, E_WARNING, "PHP-42", error)
> > >
> > > and in the init code we would register these errors:
> > > register_error_message("PHP-42", "Error %d")
> > >
> > > and now translation tables for these error messages are possible.
> > >
> > > Main problem left is that we have to stick to error-code naming rules.
> > > We should always use the extensionname followed by a number.
> > > Exeptions would be "main", "standard" and "zend".
> > >
> > > marcus
> > >
> > >
> > > --
> > > PHP Development Mailing List <http://www.php.net/>
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> >
> >
> >--
> >PHP Development Mailing List <http://www.php.net/>
> >To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
