[MPlayer-dev-eng] Sample translation lookup implementation

[Michael Niedermayer]

Hi

On Wed, Dec 06, 2006 at 09:53:00PM +0200, Uoti Urpala wrote:
> 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. 

no you dont need something to be significnat to reduce it significantly
and if i make some code 10% faster or make it use 10% less memory then
thats significant for me, you dont seem to want to accept that you are
wrong, and that string based keys have their price that fine but dont
twist the facts please, duplicating the strings all over the place needs
more space like it or not


> Can you really honestly claim
> the sample implementation I gave was that complex?

your sample implementation doesnt conform to the coding rules besides that
its not useable (= its incomplete) unless you expect people to use a hex
editor to write the translation files so the question of complexity is
unawnserable (what you send has medium to low complexity but it is not
a complete system ...)


[...]
> > 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. 

why dont you just say that every argument anyone says is irrelevant before
he even says it?

> String-based keys could be
> implemented faster;

faster then how you implemented them yes, faster then integer-keys on
normal hardware no


> 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.

then why not just call grep to find the matching string?


> 
> > 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? 

ive said that already a few times, O(1) vs O(strlen) space and time and
furthermore ive also said that this is just an example which is supperior
to string keys not that it would be a good choice its just better then
what you propose


> 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.

MSG("error file %s not found\n", 0)
the 0 is needed to take care of the case where the same string needs to be 
translated differently

vs.

MSG(MPMSG__ERROR_FILE_s_NOT_FOUND_n)

or a million other ways to design it ...
i really dont see how thats less readable

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali