Luiz Americo Pereira Camara schrieb:
When this time comes, this is what i see:
1- Most of LCL must be code page agnostic, so not use
UTF8String/AnsiString directly (keep String)
I'd use another type, e.g. LCLstring, which can be set independently
from any other automatisms.
2- It should have (dont know if currently has) a compiler switch to
change the default code page to UTF8 or whatever, so all variables with
type String will map to UTF8String.
What if a user has a different opinion, and changes the type to his
local codepage, or to UTF-16?
A boundary could be established, where strings are encoded as the *user*
specifies (i.e. generic "string"), and where the *LCL* requires a
specific (implemented) encoding.
3- The UTF8String/AnsiString type should be reserved where strictly
necessary like libraries that require UTF8 or RTL interfacing
Concrete types are required when strings are manipulated (parsed...),
and the implementation assumes a certain encoding. This should not
happen often in the LCL, but will be vital for the IDE (CodeTools...).
Properties like SelLength deserve considerations, when they currently
mean the number of logical (UTF-8) characters.
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
