I wonder if I could ask a silly question. My understanding is that strings are pretty much unique in not being objects, and relying on a fair amount of compiler and RTL wizardry to handle reference counting etc.

I note somebody at Embarcadero blogging [Paraphrase follows] "Delphi is being enhanced by adding memory management features such as reference counting".

Would there be any advantage in reimplementing strings as a tree of classes, with the compiler doing appropriate things to change e.g. Pos() into String.Pos(), UnicodeString.Pos() or whatever as appropriate?

String is the automatic reference-counted object.

But FPC team always denies this :))) citing Pascal standards of passed century.

Btw

var
  s:utf8string;
  ws:UnicodeString;
  i:=s.length();
  ws:=s.convert(UTF-16);

much more readable and causes less headache.

regards,
Anton

In our previous episode, Mark Morgan Lloyd said:

I wonder if I could ask a silly question. My understanding is that strings are pretty much unique in not being objects, and relying on a fair amount of compiler and RTL wizardry to handle reference counting etc.

And copy on write, automatic conversions/type equivalence.

I note somebody at Embarcadero blogging [Paraphrase follows] "Delphi is being enhanced by adding memory management features such as reference counting".

That's all what there is. There is simply not enough to comment on.

Would there be any advantage in reimplementing strings as a tree of classes,

A class _tree_ even? :-)

with the compiler doing appropriate things to change e.g. Pos() into String.Pos(), UnicodeString.Pos() or whatever as appropriate?

What do you think the advantages and disadvantages would be? (and obviously then, besides some minor superficial syntax change?

Are you talking about making them objects internally, or just OO like syntax instead of function(x) based ?

I admit that I was thinking of the internal implementation, and was wondering whether there was any scope for merging string support with some of the things that have been grafted onto the language since (classes, interfaces and so on).

In our previous episode, Mark Morgan Lloyd said:

I doubt it. You maybe could (and probably would) in a new language, and have one single stringtype.

FPC is closer to 20 stringtypes or types with autoconversions.

Marco van de Voort wrote

I doubt it. You maybe could (and probably would) in a new language, and have one single stringtype. FPC is closer to 20 stringtypes or types with autoconversions.

Thinking hypothetical here... what if FPC 3.0 did just that... Rethink the whole 20 string types mess, and implement only one string type for 3.0 onwards. How would developers feel about that? What would the advantages be to developers and FPC maintainers? What would the disadvantages be (other than it will probably break existing code - which the Unicode support will probably do too).

Cheers,
- Graeme -

http://xkcd.com/927/

Mattias

:-) Hence my original query about whether it could be reimplemented as a base class plus inheritance for specialisation, i.e. try to replace messy ad-hoc stuff using facilities which the underlying language has gained since its initial implementation.

Rethink the whole 20 string types mess, and implement only one string type for 3.0 onwards.
==============
No, No ! It'll 100% be slow & problematic UTF8.

In our previous episode, Graeme Geldenhuys said:

> I doubt it. You maybe could (and probably would) in a new language, and have > one single stringtype. > > FPC is closer to 20 stringtypes or types with autoconversions.

(First, while 20 sounds bad, you will keep at least ten-twelve anyway, with this way of counting (think types like char, pchar and array of char (open array dynamic and static), all in 1-byte and 2-byte versions, then literal), simply because _WE_ can standarize on one type, but the outside world won't)

Thinking hypothetical here... what if FPC 3.0 did just that... Rethink the whole 20 string types mess, and implement only one string type for 3.0 onwards. How would developers feel about that?

More, why not go wild and explorative, and use Michael Schnell's idea to use an object per char? Since it would be your fork, you can do whatever you want with it :-)

Seriously, even if you forget compatibility, it is impossible to assess something like that without in-depth design (and preferably a test implementation).

What would the advantages be to developers and FPC maintainers? What would the disadvantages be (other than it will probably break existing code - which the Unicode support will probably do too).

Read the unicode pdf. There was some deep thinking on that before D2009 came out, and some of the problems are that you never will know what is in a polymorphic string type.

Moreover, think that you will have to satisfy everybodies requirements, not just what you think you need.

Mark Morgan Lloyd wrote

Would there be any advantage in reimplementing strings as a tree of classes,

If in future TObject is reference (as it might be in a future Delphi version, according to an Embarcadero blog) counting (and thus using .Free is not mandatory any more), it seems very appropriate to have String be a sibling of TObject.

-Michael

Mattias Gaertner wrote

http://xkcd.com/927/

:-)

G.

Fully agree with you!

Automatic reference counted object with set of overloaded methods and operators suitable for any legacy string types.

Vote for this!

regards,
Anton

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 -

marcov wrote on Mon, 27 Aug 2012:

Seriously, even if you forget compatibility, it is impossible to assess something like that without in-depth design (and preferably a test implementation).

Could always look at Delphi XE3:
http://twitter.com/statuses/user_timeline/9146192.rss :)

Jonas

Michael Schnell wrote

If in future TObject is reference (as it might be in a future Delphi version, according to an Embarcadero blog) counting (and thus using .Free is not mandatory any more), [...]

I hope this will never happen.

Michael

In our previous episode, Jonas Maebe said:

Assuming you mean the stringhelper remark, that is exactly what I wouldn't do. That looks like a compatibility workaround to me, instead of reengineering without compatibility.

In our previous episode, Martin Schreiber said:

I thought everybody that wanted that had already migrated to Prism :)

Me too.

Martin

Adding helper support for primitive types was on my ToDo list anyway ^^

Regards,
Sven

+1 ! :)

Michael.