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
