[MPlayer-dev-eng] New translation system

[Rich Felker]

On Thu, Nov 30, 2006 at 04:13:40PM +0100, Attila Kinali wrote:
> On Thu, 30 Nov 2006 14:33:25 +0200
> Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> 
> > > Using strings as keys for looking up strings is idiotic and plain
> > > wrong, both semantically and in terms of implementation sanity.
> > > Indices are numbers not strings. We code in C not PHP.
> > 
> > Completely baseless drivel.
> 
> No it's not. Use such bloat and known-to-be-slow systems
> and you end up with bloatware like our current desktop systems.
> 
> You should strive to use a good performing design whenever
> you do something. The only reason why a non-good system is
> to be used, is because the good one is too complicated to
> implement. But then you have most likely a big design
> error in the surrounding system.
> 
> Indices have to be fast to look up. Which means it has to be

Uau will argue that performance here is irrelevant. He might or might
not be (mostly) right about that. But more importantly, using gettext
introduces a pile of crap that could have bugs, portability issues,
etc. and which significantly increases compile time†. I know from my
experience with building my system that including any GNU code into a
project makes for portability nightmares...

> some form of integer. If you use a string, you'd need to do
> hundreds of strcmp's.
> Of course, you can use a hash over the index string, but then you
> only hide the fact that you are using an integer as index.

No, you still have to do strcmp even with hashes because the hashes
can clash. You could alter the hash dynamically to avoid this but then
old catalog files would become useless. There is no sane solution to
the problem because it's fundamentally an insane thing to try to do..

Rich



† For a single bloated lib like gettext, compile time and other bloat
is not increased _that_ much. The problem is that a bloatware-using
app does not stop at just a single bloated lib. It adds more and more
of them over time and the bloat becomes O(t) or even O(t^2) or O(2^t)
or O(t!). :)))))