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 -

_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to