[MPlayer-dev-eng] Sample translation lookup implementation

[Uoti Urpala]

On Wed, 2006-12-06 at 19:16 +0100, Michael Niedermayer wrote:
> and just to proof that string based systems are fundamentally inferior to
> integer based ones (and iam not saying that my following suggestion is a

Obviously what you write is no "proof" of anything.

> good idea just that it provides everything string-keys provide but at
> significantly lower space and complexity)

It does not provide everything string-keys provide, and you should know
that. It requires source preprocessing or manually created macros
everywhere a translatable string is used.

It can not have "significantly lower" space and complexity requirements
unless the string key implementation first has such "significant"
requirements which could then be lowered. Can you really honestly claim
the sample implementation I gave was that complex?

Given that you really should have known your claims are false I'm
starting to wonder whether you're even trying to honestly debate the
merits of translation systems or whether you've just decided you want to
have an integer-based system, and wrote your mail only to spread FUD
about the "issues" of string keys to other people.

> simply replace every string by a unique integer, 64bit if needed, a simple
> compare is O(1) instead of O(strlen), space too is 1 vs strlen, and its of

This is all completely irrelevant. String-based keys could be
implemented faster; I didn't because it does not make any difference in
practice. When only printed strings are translated the cost of printing
them dominates anything done during the translation step.

> course simpler as its constant length

Using macros everywhere a translatable string occurs is "simpler" than
the example code I posted? That code included everything needed for
string lookup.

> now how to assign integers so they are no conflicts?
> random will do, its unlikely that a conflict will happen before we use
> 2^32 different messages and if thats not good enough then simply using
> the IP address of whoever adds the message + the time or such would
> gurantee that no conflicts can happen, and conflicts are trivial to
> resolve anyway just detect and select another integer ...

If you use random integers what advantage do those have over the English
strings? Lookup is similar, the trivial performance differences do not
matter at all in practice. On the other hand you need to do extra work
generating those integers for all translatable messages, and the sources
become less readable when you use those integers or macro names for them
instead of the real messages.