Damien Neil [mailto:[EMAIL PROTECTED]] wrote:
> This is a far more error-prone interface in a number of ways
> (...)
I don't believe that with the proper tools and rules that this system will
be any more difficult to manage. All of the things that you stated as
disadvantages could be countered with similar disadvantages with using
strings as keys. I will note that I could see using strings that look like
constants for keys, where "THREAD_EXCEPTION" is the key for the string
lookup (that's if it's deemed that this is beneficial in some way).
> (...)
> (If there is one thing that Perl
> has demonstrated, it is that looking up a string in a hash is fast.)
This isn't Perl, but Parrot (written in C), and if I understand it
correctly, that's all that this mechanism is for. Perl (and any other
language built on top of Parrot) will need to implement it's own strategy
for dealing with i18n/l10n. I suspect that Parrot will want to keep
stdout/stderr output to a minimum, as it's really the language implemented
on top of Parrot that should be catching the majority of errors.
I'd still like to hear some input from someone who's used any similar system
(gettext or other). I have, but it was in Tcl, and in Tcl "the string's the
thing" (but the system did use 'pseudo'-constants as the keys).
Grant M.
[EMAIL PROTECTED]
P.S.> I'm not dead-set against using strings, I just want to see that we do
the right thing.
