[fpc-devel] But what /is/ a string?
Graeme Geldenhuys
graeme at geldenhuys.co.uk
Mon Aug 27 12:44:04 CEST 2012
On 27/08/12 09:43, Marco van de Voort wrote:
> Seriously, even if you forget compatibility, it is impossible to assess
> something like that without in-depth design (and preferably a test
> implementation).
Wouldn't something like Java's String and Character classes already be
good in-depth reference implementation of this? Java is extremely
successful, so we know their implementation is good too. The same can be
said for Qt's QString class.
I had a quick 30 minute investigation into the Java String class. I
quite like the idea of an immutable string too. This will make
multi-threaded data access super easy - no need to worry about threads
modifying your string instance.
In FPC terms, then String class can be a reference counted IInterface
class, so we don't have to worry about freeing every string instance.
I also like the fact that in the Java String class implementation, there
is nothing left to "guess work" for the developer. Methods like
.length(), .charAt(), .codePointAt() etc are pretty self explanatory,
and if in doubt, the documentation clearly states what those method do,
what they return and how surrogate pairs (Java uses UTF-16 internally)
are handled.
I must add that Java (and Qt QString) do include some compiler magic to
make instantiation and concatenation slightly easier. But in both cases
they clearly document how it could be used, and mention pitfalls if any.
Qt's QString also has methods like .toUTF8(), .fromUTF8(),
.fromRawData(), .toLatin1(), .fromLatin1() - again making it super easy
to see what is going on and what will happen - no developer guessing
required, or having to double check the string types to see what
conversion are going to happen.
Anyway, I did say.... "hypothetically" in my first message. :)
Regards,
- Graeme -
More information about the fpc-devel
mailing list