JEP254: proposal to represent Java Strings as ISO-8859-1

Re:JEP254: proposal to represent Java Strings as ISO-8859-1 by MrBuddyCasino on Friday May 15, 2015 @10:17AM (#9550709)

That is sadly true, but at least for the Basic Multilingual Plane, charAt() and codePointAt() return correct results in constant time. The only non-broken methods are afaik codePointCount() and offsetByCodePoint(), which, as you pointed out, are not that interesting anyway.

Do you know of an example of a well-designed String API? I'd be interested in what trade-offs other language designers made (newer ones, like Rust/Swift/Go/?).

[ Parent | on HN ]

Re:JEP254: proposal to represent Java Strings as ISO-8859-1 by ygra on Friday May 15, 2015 @11:53AM (#9551399)

IMHO Python gets strings very right. The internal representation is variable, depending on the string's content (to save memory), and the external API only gives you access to code points.

[ Parent | on HN ]

Re:JEP254: proposal to represent Java Strings as ISO-8859-1 by TheLoneWolfling on Friday May 15, 2015 @01:17PM (#9552050)

The problem with Python strings is that innocuous operations can occasionally cause drastic memory usage ballooning.

A simple string append can, for instance, require up to 5x the memory consumed by the string.

Worse, this problem will only show up if someone ever enters in a high enough code point. Better hope any user-defined data never gets turned into part of a large string at any point, or you have a potential memory problem down the line.

[ Parent | on HN ]

Re:JEP254: proposal to represent Java Strings as ISO-8859-1 by gsnedders on Friday May 15, 2015 @12:02PM (#9551460)

That's only Python 3.3 and above; before that it was an under-defined mess, in CPython depending on compile-time options and often broken with the same UCS-2/UTF-16 mess as numerous other languages.

[ Parent | on HN ]