Re: [fpc-devel] But what /is/ a string?
On Monday 27 August 2012 13:40:59 Michael Fuchs wrote: Am 27.08.2012 10:51, schrieb Michael Schnell: 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. Me too. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
On 27.08.2012 13:52, Marco van de Voort wrote: In our previous episode, Jonas Maebe said: 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 :) 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. Adding helper support for primitive types was on my ToDo list anyway ^^ Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
On Tue, 28 Aug 2012, Sven Barth wrote: On 27.08.2012 13:52, Marco van de Voort wrote: In our previous episode, Jonas Maebe said: 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 :) 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. Adding helper support for primitive types was on my ToDo list anyway ^^ +1 ! :) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
On 26/08/12 13:40, 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 - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
On Sun, 26 Aug 2012 18:49:05 +0100 Graeme Geldenhuys gra...@geldenhuys.co.uk wrote: On 26/08/12 13:40, 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). http://xkcd.com/927/ Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
Mattias Gaertner wrote: 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). http://xkcd.com/927/ :-) 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
On 27/08/12 08:04, Mattias Gaertner wrote: http://xkcd.com/927/ :-) G. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
On 27.08.2012 11:51, Michael Schnell wrote: On 08/24/2012 03:14 PM, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
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
Re: [fpc-devel] But what /is/ a string?
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
In our previous episode, Jonas Maebe said: 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 :) 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
In our previous episode, Mark Morgan Lloyd said: 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). 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
On 24.08.2012 16:14, Mark Morgan Lloyd wrote: 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
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 ? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
