Hi,
concerning the string topic, for me (using fpc since 2.0.4 on a regular basis;
TP experience ~ average user) there really should be an decision what way to
go as early as possible.
I'm not ranting and I know, that I'm not in the position to demand anything...
[I would really like to help, but unfortunately studies take all my time - at
least for one more year - but time will come... :D ]
Nonetheless I would like to make a suggestion:
1.
Make a general "String" type, with no statement what the internal structure is
like.
Users can define the internal type with e.g. {$STRING UTF8} for their *whole*
project. On compilation now the defined type is used and there should be no
problems as long as the source code does not make any assumptions, what the
internal structure looks like and uses a general string unit (e.g. Sysutils).
External libraries (no source) define their string type accordingly in their
import "header" [sorry :) ] for their scope, strings are converted based on
this information, if necessary.
If you make it possible for users to define their own string unit (as
"override" of the general one), many string types are possible.
To clarify (an example; the main program file, not a unit):
...
{$STRING *user defined*}
{$USESTRINGUNIT *some user unit which implements all string ops for the own
string implementation*}
...
The advantage is, that anything compiled from source within a project
(external libraries, too) uses the user defined (=preferred) string type and
no conversion is needed (assuming there is no direct string access, which
should be good programming style nowadays).
[You see, I'm not a friend of the idea, that a string itself contains the
information about its internal type...]
2.
With this design (and most users never thinking about their own string type)
there still should be a defaul fpc string type. This is at least necessary for
string conversions. Any custom string type *must* provide a function to
convert to and from the default fpc string type, but *may* also provide such
to/from other string types.
Now any string can be (automatically) converted to any other, in the worst
case like this:
*user defined* -> fpc default -> *any other, maybe Ansistring*
There is still the problem, that conversions should be lossless, so the
default string type must be able to handle any character [but that should
obviously be possible anyway]...
... and I really hope that explicit conversions won't be necessary in future
(have I to use GetFilenameUTF8 or GetFilname or ...?? - you know)...
I can't say how much work this would be to implement, but in my eyes a more
complex but flexible solution should be worth it, thats not something you
change everyday...
... with {$STRING ANSI} it would work for any old project, so no problems in
backwards compatibility, although IMO a cut in compatability for the new
string type (supported defines, etc.) - if its necessary and makes things
cleaner - is definitely no problem and even the way to go...
3.
Now, what string type to use as default?
No suggestion from my side, but an suggestion how to quickly and
constructively find the "right" one.
Make a wiki page e.g. "new string type suggestions" where within a certain
time, everyone can describe his preferred string type, the best would be a
table with pros/cons...
... the core devs than can decide based on this.
[Basically summarized info of all the posts floating around in the mailing
list]
-> So, don't waste your energy one more time, to fight each other in response
to this post, just fill the wiki page :)
[IMHO nobody will ever read all the postings about strings in the mailing
list, there *must* be a summarized overview somewhere]
[Sorry if this wiki page already exists...]
And a last thought from my side:
Please, don't try to stay Delphi compatible no matter what.
IMHO its time for fpc to move forward, not sticking to any (bad) Delphi design
change. Even now its almost impossible to use ("modern") Delphi code 1:1 in
fpc, and it certainly won't be better in future. It would be much better to
define a "last almost supported Delphi version" and then go an own way.
Fpc (and Lazarus even more) shouldn't be reduced to "make any Delphi(!)
project crossplatform" - and doing the difficult (not to say "dirty") work for
Embarcadero to make a Windows-oriented design work on many platforms - it
should be an independant implementation of ObjectPascal (and not Delphi!), in
the optimal case being compatible to Delphi, as long as its possible and makes
sense...
With the above suggestion, it would be even possible to make an own Delphi
compatible string type for Delphi mode.
- And, if the Delphi design really is superior to any other - then lets use it
(unfortunately its not).
Uff, a long post, hopefully at least a little helpful - and constructive.
Certainly many wait for the final decision (including me) - let's hope it will
come in near future... :D
Regards,
d.l.i.w
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
