[fpc-devel] Unicodestring branch, please test and help fixing

[listmember]

> So maybe the design is quite well thought?

Adding a flag field is easy enough --if all you're doing is to do some 
sort of collation. In that sense, everything is well tought out.

But..

Life becomes very complicated when you begin to do things like FTS (full 
text search) on a multilanguage text in a DB engine.

Your options, in this case, is just very limited:

   -- Ignore the langage issue.
or
   -- store each language in a different field (that is if you know how 
many there will be).

Do you think this is a good solution --or, a hack.

> As for Storing info per string or per char. (Info could be anything:
> collation, color, style, font, source-of-quote, author, creation-date,
> file, ....) everyone would like there own. So again FPC shouldn't do it.
> Or everyone gets all the overhead of what all the others wanted.

Collation is a function of language.

All the others are not an intrinsic part of o a char at all --they vary 
by context.

> Also FPC is a programming language. Not a word processing tool

Well, they should have remembered that before they added in char and 
string types when everything could perfectly be represented with a byte.

> Then instead of asking for strings as object, I would ask for an
> additional ref-counted object type (with auto destruction). The string
> library could be based on this. I am not asking for suxch a think
> because a) it wouldn't be pascal anymore. b) beware of the mem-leaks

Personally, I gave up on strings as objects on the compiler level. That 
could, of course be added as a lib.

> If pascal doesn't suit the need of a specific task, choose a different
> tool. Instead of inventing a new pascal.

Thank you for the advice.

But, instead of jailing this discussion to at best a laterally relevant 
issue of collation, can I ask you to think for a moment:

How on earth can you do a case-INsensitive search in *any* given string 
contains multiple language substrings?

Please note the 'case-INsensitive' keyword there.

> Btw in normal math you can not devide a number by zero... Of course you
> can define your own math

And, the point is??..